Tudo começou quando Bob Martin, mais conhecido como Uncle Bob publicou em seu twitter:
TDD garante cobertura de testes
TDD ajuda, mas não garante, um bom design e um bom código. Habilidade, talento e conhecimentos continuam a ser necessários.
Esko Luontola em seu blog acha que uma boa cobertura de testes não necessariamente garante que existirá uma boa qualidade no design da aplicação. Em seu post ele elege alguns pontos de como a prática do TDD pode indiretamente e diretamente impactar no design do código.
Esko diz que os efeitos diretos levando em consideração as três regras do TDD são:
- Garante cobertura de testes
- Aumenta o sofrimento quando tem-se um código mal escrito
Já os efeitos indiretos, quando existem programadores experientes na prática de TDD são:
- Permite alterar o código sem quebrá-lo
- Melhora a qualidade do código
Ele vai além e discute os pontos diretos e indiretos mais a fundo.
Garantia de código coberto por testes
Ele diz que se os programadores seguem as regras do TDD com disciplina, obviamente irão alcançar cobertura de testes total, visto que não deve ser feito nenhum tipo de código que não seja iniciado em um teste.
Aumenta o sofrimento quando tem-se um código mal escrito
No TDD, depois de escrever um teste que falha, o passo seguinte é torná-la passar com o mais simples possível mudança. Porém, para ser capaz de testar alguma coisa, o código deve ser testável, ou seja, tem que ser um código coeso e com baixo acoplamento.
Esko diz que o TDD sempre leva a um código que tem que ser mudado o tempo todo, e se o código for de difícil manutenção ele será difícil de mudar. Além disso se o código não for testável será muito difícil criar testes para ele. Ele reforça a tese e diz:
...TDD aumenta a dor causada por um código ruim, porque não é possível evitar a mudança desse código, nem evitar escrever testes para ele.
Permite alterar o código sem quebrá-lo
A cobertura de testes que permite que seja percebido que um código está quebrado, mas isso segundo Esko não é o suficiente para que seja alterado de uma forma segura.
É necessária habilidade para ser capaz de modificar o código em pequenos passos de maneira segura. O desenvolvedor precisa ter a capacidade de fazer grandes alterações no design, combinando-as com múltiplas pequenas refatorações, fazendo com que os testes passem após cada uma delas.
Isso requer habilidade e disciplina. Um desenvolvedor desqualificado ou indisciplinado iria se perder no refactoring, ou iria desistir e abandonar os testes.
Melhora a qualidade do código
Os efeitos de sentir a dor na hora de alterar o código ou criar os testes, e do processo de fazer pequenas mudanças seguras garantam que o código tenha mais qualidade. Esko diz uma frase bem interessante que é:
O ponto importante é "ouça os testes".
Quando o teste ou uma alteração forem difíceis de serem feitos com TDD, o desenvolvedor deve ser sensível e sentir aquela dificuldade e tentar resolvê-la da melhor maneira possível.
Esko diz que o importante é notar as dificuldades o mais rápido possível e tentar solucioná-las e não fazer diferente deixando o problema como está e tornando a vida do próximo desenvolvedor a mexer naquele código complicada.
E você leitor? Como utiliza TDD a seu favor?