🎯 1.11 Estratégias de Teste: Casos de Borda e Partições
Na engenharia de software, a qualidade de uma suíte de testes não é medida pela quantidade de testes, mas pela sua capacidade de revelar bugs. Para isso, precisamos dominar o teste de Casos Especiais (Edge Cases) e Valores de Limite.
🏗️ Por que testar o “Óbvio”?
É comum focarmos no “Caminho Feliz” (Happy Path) e esquecermos de cenários simples que ocorrem frequentemente em produção. Quando lidamos com coleções (Listas/Arrays), três estados são fundamentais:
- Lista Vazia: O sistema lança uma exceção ou retorna zero?
- Lista com Um Elemento: O algoritmo de comparação funciona corretamente?
- Lista com Múltiplos Elementos: A lógica de iteração está correta?
📉 Análise de Valor de Limite (Boundary Value Analysis)
Muitos bugs residem exatamente na fronteira das condições lógicas. Um simples erro de digitação trocando um > por um >= pode comprometer toda a regra de negócio.
📄 Exemplo: Cálculo de Bonificação
Considere o seguinte trecho de código Java:
public double calcularBonificacao(double salario) {
if (salario >= 2000.0) {
return salario * 0.1;
}
return salario * 0.05;
}Para garantir a cobertura total, precisamos de três partições de equivalência:
flowchart LR A["Salário < 2000 (Ex: 1999)"] -- 5% --> B{"Ponto de Corte (2000)"} B -- 10% --> C["Salário > 2000 (Ex: 2001)"] style B fill:#fff,stroke:#e74c3c,stroke-width:4px
O Desafio da Cobertura 🛡️
O grande desafio da área de testes é identificar quais valores de entrada farão seu sistema falhar. Testar ordem crescente, decrescente e randômica é essencial quando a ordenação interfere no resultado final (como no nosso
Avaliador).
🛠️ Checklist de Casos Especiais
✔ Strings: Nulo, Vazio (""), Apenas espaços (" ").
✔ Números: Zero, Negativos, Valores Máximos (MIN_VALUE, MAX_VALUE).
✔ Datas: Virada de ano, anos bissextos, fusos horários diferentes.
Dica Didática 🚀
Se você testou o limite (ex: 2000) e os valores imediatamente vizinhos (1999 e 2001), você cobriu estatisticamente a maioria dos erros de lógica condicional. 🏁