Testes são mais do que regressão: os benefícios no design

O resultado da execução do trecho de código é o conjunto de efeitos colaterais e o retorno da chamada efetuada. As asserções que fazemos em um código de teste verificam que esse conjunto de efeitos e retorno são exatamente o esperado. Em código, é algo como instanciar uma classe, invocar um método e verificar sua saída:

Portanto, o teste automatizado é basicamente um trecho de código que exercita algum trecho de código de produção. E, se a criação desse teste for um processo difícil e trabalhoso, isso é um indicador claro que a utilização desse código é também difícil e trabalhosa: há um problema na maneira que o código vai ser utilizado.

Imagine um trecho que possui 100 linhas de código, incluindo diversos condicionais dependente de variáveis no escopo, e que precisa ser testado. Assim como no momento de utilização desse código, a preparação envolve atribuir valor a todas as variáveis que influenciam no fluxo de condicionais e loops: um processo geralmente penoso para um código de 100 linhas.

O seu teste, aquele trecho de código que faz uso do método de produção, indica que o código existente está executando muita coisa - e é óbvio, são 100 linhas, ele assumiu muitas responsabilidades com o passar do tempo (e agora é a hora de quebrar tal comportamento em diversas partes). O feedback que o teste dá - criado antes ou depois do código funcional, e mostrando a complexidade - é um reforço para perceber momentos de refatoração.

Se o código testado é uma unidade pequena, e for difícil testá-lo, o feedback indica que ele há algo nocivo na comunicação dessa unidade com as quais ela se integra, conforme o diagrama a seguir:

Se o código testado envolve diversas unidades (na verdade, o que chamamos de um teste de integração), o feedback é sobre a comunicação somente entre duas pontas, perdendo qualquer benefício em relação ao design de suas unidades:

Se você analisar seu teste com cuidado, você verá que um determinado tipo de problema no código de teste pode implicar em um determinado problema na classe de produção. Por exemplo, se sua bateria de testes de uma única classe tem 50 métodos de testes, isso nos diz que a classe de produção tem 50 comportamentos diferentes, o que pode nos indicar problemas de coesão. Se a classe de teste faz uso de muitos mock objects para isolar, isso pode nos indicar que a classe de produção tem problemas de acoplamento. E sobre a vontade que temos de vez em quando de testar métodos privados? Podemos pensar em muitas coisas que "podem dar errado" em nosso teste.

Esses feedbacks podem nos ser extremamente úteis. No livro de TDD da Casa do Código, o Maurício Aniche discute e elenca uma série desses padrões. Nosso curso de Práticas Ágeis de Desenvolvimento de Software também.

E você, já usa seus testes de unidade para aprender e melhorar seu design de classes?