Escrever testes de unidade durante o desenvolvimento de código novo nem sempre é tarefa fácil.

Muitas vezes, dependendo da complexidade, é difícil antecipar, de maneira eficiente, a estrutura final do software. Diversas decisões de design precisam ser feitas enquanto o código é escrito e, com frequência, elas são revistas, mais de uma vez, antes que uma primeira entrega estável seja feita.

Consideremos, por exemplo, a escrita de um avaliador de expressões matemáticas que suporte variáveis. Seguramente, a solução final contemplará algum nível de análise sintática e semântica. Também deverá incluir algum modelo de representação em memória e algum mecanismo de otimização. O certo é que boa parte do design irá emergir na medida que a implementação avançar.

[Fact]
public void ShouldEvaluateDivisionsBeforeAdditions()
{
   ExpressionEvaluator.Eval(“2+2/2”).Should.Be(3)
}

Geralmente é perda de tempo escrever testes de unidade para código com “design instável”, por isso, recomenda-se “subir o teste” até um ponto onde já tenhamos alguma “certeza”. No caso do avaliador de expressões, o ideal é escrever um teste “contra” a interface que recebe a expressão e devolve o resultado e “caminhar” com o código até que existam indícios de estabilidade em níveis mais “baixos” de implementação.

Importante entender que esse “nível” de teste é útil para garantir que a solução como um todo está funcionando. Entretanto, ela seguramente não oferece nível suficiente de isolamento para, por exemplo, explicar como o código funciona para os desenvolvedores, tampouco para demonstrar, em caso de falhas, onde o erro está (exceto quando executados com muita frequência durante a escrita do código)