Já é lugar comum a importância de testes automatizados em desenvolvimento de software. Não somente pela confiança que eles dão ao desenvolvedor na hora de fazer refatorações e correções de bug, mas também porque para ter testes em todos os níveis, o código precisa necessariamente ser testável.
Código testável, isto é, aquele em que dependências podem ser facilmente isoláveis, não é algo sempre trivial de fazer. Normalmente requer um design mais criterioso em que os pedaços de código sejam distribuídos em classes pequenas e coesas, caso contrário, os testes ficam muito grandes, trabalhosos e as vezes até mesmo impossíveis de fazer.
Sendo assim, a presença de testes está não somente influenciando pela sua presença per se, mas também pela consequente melhora no design que a inclusão deles forçou acontecer.
É por isso que era um pouco reticente com TDD. Se o programador não abre mão dos testes, pra mim pouco importava se os testes eram escritos antes ou depois da feature propriamente dita.
Entretanto com o tempo acabei mudando de opinião. Acredito que design (pensar em como resolver o problema) e codificação (a escrita de código) não são atividades isoladas. É necessário codar para ter insights sobre o design, assim como para codar é necessário pensar no design que se quer atingir. Design e codificação são atividades que devem andar juntas pois há uma simbiose natural nelas.
Portanto, para mim, a forma de codar mais efetiva é aquela em que mescla design e codificação o máximo possível para um retroalimentar o outro, num algoritmo que seria mais ou menos assim:
- Coda um pouquinho
- Analisa o design da solução
- Volta pro passo 1 até terminar a feature
Codando dessa maneira, TDD se encaixa como uma luva no desenvolvimento, pois cada caso de teste e sua implementação até ficar verde ficam sendo a perfeita unidade de medida e ponto para reavaliar o andamento do design.
Nenhum comentário:
Postar um comentário