Teste de caixa branca

O teste de caixa branca (white-box testing) projeta os testes lendo o código. O tester (muitas vezes o próprio desenvolvedor) olha os branches, as condições, os loops e o tratamento de erros e escreve testes que os exercitam de propósito. Ele também é chamado de teste de caixa de vidro (glass-box), caixa transparente (clear-box) ou teste estrutural. Os testes unitários são a forma mais comum, e a cobertura de código é a sua medida habitual.

Exemplo

String grade(int score) {
    if (score < 0 || score > 100) {
        throw new IllegalArgumentException("score out of range");
    }
    if (score >= 50) {
        return "PASS";
    }
    return "FAIL";
}

Lendo o código, você vê três resultados (exceção, PASS, FAIL), e o primeiro if tem duas condições separadas, e cada uma delas pode disparar a exceção. Testes escolhidos a partir da estrutura:

Entrada	Caminho exercitado
-1	score < 0 verdadeiro, exceção
101	score > 100 verdadeiro, exceção
50	dentro do intervalo, score >= 50 verdadeiro, PASS
49	dentro do intervalo, score >= 50 falso, FAIL

Esses testes dão cobertura total de branches e de condições. Testar exatamente 50 e 49 também pega um >= escrito sem querer como >.

Caixa branca vs caixa preta

A caixa branca pergunta “cada caminho deste código se comporta corretamente?” e precisa do código-fonte. A caixa preta pergunta “o sistema faz o que os requisitos dizem?” e precisa apenas da especificação. A caixa branca encontra caminhos não testados, código morto e erros de lógica nos branches. A caixa preta encontra funcionalidades ausentes e comportamentos que contradizem os requisitos, o que a caixa branca não enxerga, porque não existe código para uma funcionalidade que falta. Boas suítes usam as duas.

Limites

• Os testes podem copiar os erros do código. Se o desenvolvedor entendeu mal o requisito, testes escritos a partir do código vão confirmar o comportamento errado.
• Acoplamento forte. Testes que dependem de métodos privados ou da estrutura interna quebram a cada refatoração, mesmo quando o comportamento não muda. Sempre que possível, teste pelas interfaces públicas.
• Cobertura não é corretude. Executar todos os branches não diz nada sobre as assertions serem significativas.