Como você pode se considerar um profissional se você não sabe se todo seu código funciona? Como você pode saber se todo seu código funciona se não testa ele toda vez que faz uma mudança? Como pode testar seu código todo, toda vez que faz uma mudança se você não tem testes de unidade com um alto índice de cobertura?
Como você pode ter um alto índice de cobertura por testes automatizados sem praticar TDD?(Uncle Bob)
Perguntas difíceis! Não é mesmo?
De forma geral, concordo com todos os questionamentos propostos (e suas conclusões), e, como Uncle Bob, tenho dificuldades em perceber um código com baixa cobertura de testes automatizados como tendo sido desenvolvido por um bom profissional. Entretanto, não penso que a única maneira de atingir este alto índice de cobertura seja através da prática do TDD.
Não me entenda mal. Já fui praticante, até mesmo defensor, da prática de desenvolvimento/design orientado por testes. Mas, não sou mais! Atualmente, tendo a acreditar, inclusive, que essa prática mais atrapalha do que ajuda.
Salvo quando estou corrigindo bugs, onde acho muito prático e razoável escrever um teste que demonstre a falha primeiro, para depois iniciar meus esforços de correção, abandonei a prática do TDD completamente.
Como trabalho?
Basicamente, meu processo de desenvolvimento pode ser descrito em três momentos distintos. Sendo os dois primeiros:
- Experimentação – Quando estou criando algo, costumo não me preocupar tanto com design do código, qualidade ou organização. Se tenho algum teste, este é bem genérico, geralmente indicando algum caso de sucesso. Quase nunca este teste é de unidade. Nesse momento, o importante é “botar para fora” a idéia que está na minha cabeça.
- Estabilização – Tendo criado uma base de código relevante que representa a visão (geralmente caótica) que eu tinha de como resolver o problema, começa a fase de estabilização. Aqui, a ideia é tentar aplicar alguma organização e, aqui, começam a ser escritos alguns testes. Os testes, quase sempre, me ajudam a polir o meu código. Como desenvolvo APIs, são os testes que me ajudam a perceber oportunidades de melhoria.
Fico alternando fases de experimentação e estabilização sem me preocupar muito com os tempos destinados a cada uma delas. Geralmente, no início de uma tarefa, costumo ser mais experimental. Então, na medida que o projeto avança, aumento meus esforços de estabilização.
A chave, penso eu, para conseguir ter boa cobertura de testes automatizados é ser exigente na fase de estabilização. De forma geral, não consigo entender um código como estável sem que ele atinja por volta de 90% de cobertura.
Por fim, com meu código estabilizado, entro em um último momento:
- Otimização – Costumo não perder muito tempo pensando em performance quando estou nos momentos “experimentação” e “estabilização”. Ali as ideias são outras. As primeiras versões dos meus códigos costumam ter performance bem ruim. As últimas costumam ser realmente rápidas (e economicas em termos de recursos computacionais).
IMPORTANTE: Não inicio nenhuma OTIMIZAÇÃO em código que não esteja ESTABILIZADO (ou seja, com ótima cobertura por testes automatizados).
Resumindo, meu processo é Experimenta – Estabiliza – Otimiza.
Gostaria de ser praticante de TDD. Mas, ao longo de todos esses anos, confesso que a ideia acabou não funcionando para mim.
Como é o seu processo?
