Qualidade, testes, revisão de código e refatoração

Do zero

Um carro de qualidade não é só o que anda: é o que anda rápido quando precisa (desempenho), aguenta a família toda na viagem (escalabilidade), liga toda manhã (disponibilidade), não quebra no meio da estrada (confiabilidade) e é fácil de consertar na oficina (manutenibilidade). Software é julgado pelas mesmas qualidades.

Testar é verificar essas qualidades antes que o usuário descubra o problema. Pense na fábrica do carro: testa-se cada peça sozinha (teste unitário), depois as peças montadas juntas (integração), depois o carro inteiro numa pista (sistema ou funcional) e, por fim, o cliente faz o test drive (aceitação). Sempre que se troca uma peça, confere-se se o resto continua funcionando (regressão).

Com o tempo, todo código acumula remendos. Refatorar é arrumar a casa sem mudar o que ela faz: reorganizar o código para ficar mais simples, mantendo o mesmo comportamento. Dívida técnica é o nome do remendo que se deixou para depois: como uma dívida, cobra juros a cada nova mudança.

Frase para guardar: testa-se do pequeno para o grande; refatorar muda a forma, não o comportamento; dívida técnica cobra juros.

Em 1 minuto

• Qualidades: desempenho, escalabilidade, disponibilidade, confiabilidade e manutenibilidade.
• Níveis de teste: unitário, integração, sistema e aceitação. Teste funcional é um tipo, não um nível: verifica, como caixa-preta, se o sistema faz o que os requisitos funcionais pedem, e pode ser aplicado em qualquer nível. Regressão confirma que o que funcionava continua funcionando depois de uma mudança.
• Carga testa o volume esperado e de pico; estresse vai além do limite, para ver como o sistema falha e se recupera.
• Caixa-preta testa entradas e saídas sem olhar o código (classes de equivalência, valor-limite); caixa-branca usa a estrutura interna (cobertura de comandos e caminhos).
• Pirâmide de testes: muitos unitários (rápidos e baratos), menos de integração, poucos de ponta a ponta.

Exemplo concreto: a emissão de certidões

Valor-limite: se o campo “exercício” aceita de 2015 a 2026, os testes mais valiosos são 2014, 2015, 2026 e 2027, porque os erros se concentram nas bordas. Classes de equivalência: um valor de cada faixa (abaixo, dentro, acima) representa a faixa inteira.

Disponibilidade em números: 99,9% de disponibilidade permite cerca de 43 minutos de indisponibilidade num mês de 30 dias (0,1% de 43.200 minutos) e cerca de 8,8 horas num ano.

Comparação: carga, estresse e as qualidades

Revisão de código, refatoração e dívida técnica

• Revisão de código: outra pessoa lê a mudança antes de ela entrar (no pull request), procurando erros, falhas de segurança e código confuso. Na forma mais rigorosa, a inspeção, há papéis definidos e checklist.
• Refatoração: melhorar a estrutura interna sem alterar o comportamento externo. Os sinais de que é preciso (“code smells”) incluem código duplicado, método longo demais e classe com responsabilidades demais. Testes automatizados são a rede de segurança: rodam antes e depois para provar que nada mudou.
• TDD (desenvolvimento guiado por testes): escreva um teste que falha (vermelho), escreva o mínimo de código para passar (verde) e refatore.
• Dívida técnica: atalhos tomados para entregar antes (falta de testes, gambiarras, documentação adiada). Pode ser consciente e até razoável, mas precisa ser registrada e paga, ou cada mudança futura fica mais cara.

Como a FCC cobra

• Níveis e tipos de teste e o objetivo de cada um.
• Caixa-preta × caixa-branca; valor-limite e classes de equivalência.
• Refatoração (muda a estrutura, não o comportamento).
• Dívida técnica e suas consequências.
• Atributos de qualidade e escalabilidade vertical × horizontal.

Pegadinhas

Explique com suas palavras

Explique a um gestor por que vale a pena ter testes automatizados de regressão, e o que é dívida técnica, com um exemplo seu.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Toda mudança num sistema pode quebrar algo que já funcionava, às vezes numa parte que ninguém imaginaria. Testes de regressão automatizados conferem, em minutos e a cada mudança, que o que funcionava continua funcionando. Sem eles, ou se testa tudo à mão, o que é lento, ou se descobre o erro em produção, com o usuário.

Dívida técnica é deixar um remendo para depois para entregar antes. Por exemplo, copiar e colar o mesmo cálculo em três telas em vez de criar uma função só. Funciona hoje, mas, quando a regra mudar, será preciso lembrar de alterar os três lugares, e esquecer um vira erro. Esse trabalho extra a cada mudança são os juros da dívida.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Em casos sobre código gerado por IA ou sobre um pipeline de CI/CD, testes são o portão de qualidade: “testes unitários e de integração automatizados rodam a cada mudança, e o deploy é bloqueado se algum falhar; testes de carga antes de períodos de pico, como o fim do prazo de prestação de contas”. Some a revisão de código humana no pull request.

Fontes da lição

• Edital nº 01/2026, Anexo II, Engenharia de Software (fontes/edital-01-2026.txt).
• Ian Sommerville, Engenharia de software (níveis de teste, verificação e validação).
• Martin Fowler, Refatoração (definição de refatoração e “code smells”).
• Ward Cunningham, “The WyCash Portfolio Management System” (1992), origem da metáfora da dívida técnica.