Testing

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

Testes documentam o comportamento esperado numa forma que a máquina consegue conferir. Um teste que falha precisa contar quem chamou, o que recebeu e o que esperava receber. Quando o teste não deixa isso legível, ele continua verificando o código, mas deixa de documentá-lo.

O padrão AAA (Arrange, Act, Assert · Arranjar, Agir, Atestar) tem três fases lógicas, mas apenas duas partes visuais. As declarações (o contexto, a execução e os valores nomeados) formam um bloco só. Uma linha em branco isola a asserção.

[Arrange]  montar o contexto: entidades, inputs, dependências
[Act]      executar o comportamento e nomear actual/expected

[Assert]   comparar com variáveis nomeadas

Essa separação visual faz parte do padrão. A linha em branco antes da asserção diz onde o preparo termina e a verificação começa. Sem ela, as fases se misturam e o leitor precisa descobrir sozinho onde uma acaba e a outra começa, antes mesmo de entender o que está sendo testado.

A asserção segue o mesmo princípio do retorno explicativo no código: nomeie os valores antes de comparar. Ela deve se ler como uma frase, sem cálculo nem acesso a propriedade no meio.

actual e expected são declarados antes da asserção, sempre. Mesmo quando o valor já carrega um nome, declarar expected de forma explícita mantém o padrão previsível e a comparação sem ambiguidade.

O nome descreve o cenário e o resultado esperado. Prefixos como should, test_ ou given/when/then ocupam espaço sem informar nada.

Nenhum teste depende de outro para funcionar, e a ordem de execução não pode importar. Estado compartilhado entre testes cria um acoplamento difícil de perceber: a falha só aparece em determinada ordem e não se reproduz quando o teste roda sozinho.

Verificam o comportamento de uma unidade isolada: uma função, um método, uma classe. Sem banco, sem rede, sem sistema de arquivos. Quando há dependência externa, ela é substituída por um double (stub, mock ou fake).

A velocidade é a característica central. Rodam em milissegundos e não pedem infraestrutura, o que os torna a ferramenta certa para feedback imediato durante o desenvolvimento e para cobrir casos de borda à exaustão.

Verificam se múltiplos componentes funcionam juntos, usando infraestrutura de verdade: banco de dados, APIs externas, filas, sistema de arquivos.

O custo é o setup: precisam de ambiente, demoram mais e têm mais variáveis envolvidas. Em troca, verificam o que o teste unitário não alcança: se a SQL (Structured Query Language · Linguagem de Consulta Estruturada) gerada está correta, se a migration não quebrou o mapeamento, se o endpoint devolve o contrato esperado.

Um erro comum é usar muitos mocks para simular o banco num teste "unitário" de repositório. O repositório existe para conversar com o banco, então testá-lo contra um banco falso verifica quase nada. Repositório é candidato natural a teste de integração.

O que separa os dois é a pergunta que cada um responde. O unitário verifica se a lógica está correta. O de integração verifica se as peças funcionam juntas com infraestrutura real. Os dois são necessários e cobrem coisas diferentes.

lógica isolada (funções, cálculos, validações) → unitário
limite com I/O real (banco, rede, fila)        → integração

A cyclomatic complexity (complexidade ciclomática) conta quantos caminhos independentes existem dentro de uma função. Uma função em linha reta tem complexidade 1, e cada if, else if, case, laço, &&, || e catch soma mais um.

Isso tem consequência direta no teste: uma função de complexidade N exige pelo menos N casos para cobrir todas as ramificações. Complexidade alta também concentra risco, porque uma mudança pequena passa a atingir vários caminhos de uma vez.

Passou de 10, as saídas são as mesmas que valem para funções longas:

DoDocs v3.7.0 · Desenvolvido por @thiagocajadev · Baseado no trabalho de pmndrs/docs · Poimandres.