Testing

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

Testes documentam o comportamento esperado. Um teste que falha conta uma história: quem chamou, o que recebeu, o que esperava.

O padrão AAA (Arrange, Act, Assert · Arranjar, Agir, Atestar) divide cada teste em três fases explícitas, separadas por uma linha em branco.

[Arrange]  montar o contexto: entidades, inputs, dependências

[Act]      executar o comportamento sob teste

[Assert]   verificar o resultado com variáveis nomeadas

A separação visual é parte do padrão. Cada linha em branco entre fases é intencional: sinaliza onde termina o contexto, onde acontece a execução e onde está a verificação. Um teste sem separação mistura as três fases e obriga o leitor a identificar os limites antes de entender o que está sendo testado.

O assert segue o mesmo princípio do retorno explicativo no código: variáveis nomeadas antes da comparação. O assert lê como uma frase, sem cálculo nem acesso de propriedade inline.

actual e expected são declarados antes do assert, sempre. Mesmo quando o valor já tem nome, declarar expected explicitamente mantém o padrão consistente e o assert sem ambiguidade.

O nome descreve o cenário e o resultado esperado. Prefixos como should, test_, given/when/then não agregam informação.

Cada teste monta seu próprio contexto. Nenhum teste depende de outro para funcionar: a ordem de execução não deve importar. Estado compartilhado entre testes é o tipo de acoplamento mais silencioso, pois falhas dependem da ordem de execução e são difíceis de reproduzir isoladamente.

Verificam o comportamento de uma unidade isolada: uma função, um método, uma classe. Sem banco, sem rede, sem sistema de arquivos. Dependências externas são substituídas por doubles (stubs, mocks, fakes) quando necessário.

Velocidade é a característica central: rodam em milissegundos, sem setup de infraestrutura. Isso os torna adequados para feedback rápido durante o desenvolvimento e cobertura exaustiva de casos de borda.

Verificam como múltiplos componentes funcionam juntos, com infraestrutura real: banco de dados, APIs externas, filas, sistema de arquivos.

O custo é o setup: precisam de ambiente, são mais lentos e têm mais variáveis. O benefício é verificar o que testes unitários não alcançam: que a SQL (Structured Query Language, Linguagem de Consulta Estruturada) gerada está correta, que a migration não quebrou o mapeamento, que o endpoint retorna o contrato esperado.

Um erro frequente é usar mocks extensivos para simular o banco em testes "unitários" de repositório. O repositório existe para falar com o banco: testá-lo com banco falso verifica quase nada. Repositórios são candidatos naturais a testes de integração.

A distinção é o que cada tipo verifica. Testes unitários verificam se a lógica está correta. Testes de integração verificam se os componentes funcionam juntos com infraestrutura real. Os dois são necessários e se complementam.

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

Complexidade ciclomática (cyclomatic complexity) mede o número de caminhos independentes em uma função. A complexidade mínima é 1 (linha reta); cada if, else if, case, loop, &&, || e catch soma +1.

A métrica tem uma consequência direta nos testes: uma função com complexidade N exige pelo menos N casos de teste para cobertura de branch (cobertura de ramificações). Funções com complexidade alta concentram risco: uma mudança pequena pode quebrar múltiplos caminhos.

Quando a complexidade supera 10, as ações são as mesmas que para funções longas:

Desenvolvido por @thiagocajadev · Fork baseado no repositório pmndrs/docs · Poimandres.