Um artigo publicado inicialmente no jornal Empirical Software Engineering afirma: "TDD parece ser aplicável em vários domínios e pode reduzir significantemente a densidade de defeitos de software desenvolvido sem reduzir significantemente a produtividade do time de desenvolvimento." O estudo comparou 4 projetos, na Microsoft e na IBM, que usaram TDD com projetos similares que não usaram TDD.
O artigo é de autoria de Nachiappan Nagappan (Microsoft), E. Michael Maximilien (IBM), Thirumalesh Bhat (Microsoft), e Laurie Williams (North Carolina State University), e publicado no Volume 13, Número 3 do jornal Empirical Software Engineering. Ele está também disponível no Grupo de Engenharia de Software Empírica da Microsoft Research.
O artigo inclui 1 estudo de caso na IBM e 3 na Microsoft. Cada um dos estudos de caso compara dois times trabalhando no mesmo produto, usando as mesmas linguagens de desenvolvimento e tecnologias, reportando ao mesmo gerente, e apenas um deles estava usando test-driven development (TDD). Nenhum dos times sabia que eles fariam parte do estudo durante o seu ciclo de desenvolvimento. O caso de estudo da IBM acompanhou times trabalhando em drivers de dispositivo. Os casos da Microsoft acompanharam times trabalhando em Windows, MSN e Visual Studio.
O artigo descreve as práticas de TDD usadas pelos times como fluxos de trabalho minuto-a-minuto, bem como fluxos de trabalho em nível de tarefas.
Fluxo de trabalho minuto-a-minuto
- Escreva um número pequeno de testes novos
- Rode os testes e veja-os falharem
- Implemente código para satisfazer os testes
- Rode novamente os novos casos de teste para ter certeza que eles passam
Fluxo de trabalho em nível de tarefa
- Integre código novo e testes dentro do código existente
- Rode novamente todos os casos de teste para ter certeza que o novo código não quebra alguma coisa
- Refatore a implementação e/ou código de teste
- Rode novamente todos os testes para ter certeza que o código refatorado não quebra alguma coisa
A densidade de defeito pré-lançamento dos quatro produtos, medida como defeitos por milhares de linhas de código, diminuiu entre 40% e 90% em relação aos projetos que não usaram TDD. As gerências dos times reportaram subjetivamente um aumento de 15-35% no tempo inicial de desenvolvimento para os times usando TDD, apesar de que os times concordaram que esse tempo foi compensado pela redução de custos de manutenção.
Estes resultados podem ser comparados com aqueles encontrados em um artigo publicado em 2006 por Maria Siniaalto. Esse artigo tentou resumir e resenhar os resultados de outros 13 estudos em test-driven development, incluindo pesquisa conduzida em contextos industrial, semiindustrial e acadêmico. Entre as conclusões do artigo, o a autora escreveu:
Baseado nas descobertas dos estudos existentes, pode-se concluir que TDD parece melhorar a qualidade de software, especialmente quando empregado em um contexto industrial. As descobertas não foram tão óbvias nos contextos semiindustrial ou acadêmico, mas nenhum desses estudos reportou queda na qualidade. Os efeitos na produtividade do TDD não foram muito óbvios, e os resultados variam independentemente do contexto do estudo. Porém, houve indícios de que TDD não necessariamente diminui a produtividade do desenvolvedor ou aumenta o tempo de desenvolvimento do projeto: Em alguns casos, melhorias significantes de produtividade foram alcançadas com TDD enquanto que apenas dois dos treze estudos reportaram queda de produtividade. Porém, em ambos estudos a qualidade foi melhorada.
Quais são as suas experiências com TDD? Você notou um aumento na qualidade? Que efeitos você viu na produtividade do desenvolvedor, e tempo de desenvolvimento? Deixe um comentário e compartilhe suas experiências.