Procurando estudos de caso de como o TDD melhorou a qualidade e / ou a velocidade do desenvolvimento [fechado]

Na minha empresa, estou tentando argumentar por que deveríamos fazer TDD. Atualmente, a maioria dos desenvolvedores faz o possível para concluir o projeto e depois adiciona testes de unidade após o fato para atender às métricas do gerente. Todos os exemplos de empresas conceituadas que fazem TDD e vêem os benefícios serão muito apreciados.

Um estudo de 4 projetos na IBM e Microsoft. Publicado na revista Emperical Software Engineering .

Estudos empíricos mostram que o desenvolvimento orientado a testes melhora a qualidade

Um artigo publicado pela primeira vez na revista Empirical Software Engineering relata: "O TDD parece ser aplicável em vários domínios e pode reduzir significativamente a densidade de defeitos do software desenvolvido sem uma redução significativa da produtividade da equipe de desenvolvimento". O estudo comparou 4 projetos, na Microsoft e na IBM, que usavam TDD com projetos semelhantes que não usavam TDD ...

O artigo inclui 1 estudo de caso na IBM e 3 da Microsoft. Cada um dos estudos de caso compara duas equipes que trabalham no mesmo produto, usando as mesmas linguagens e tecnologias de desenvolvimento, sob o mesmo gerente de nível superior, apenas uma delas usando o TDD (Test-driven Development). Nenhuma das equipes sabia que faria parte do estudo durante seus ciclos de desenvolvimento. O estudo de caso da IBM acompanhou as equipes que desenvolviam o driver de dispositivo. Os casos da Microsoft seguiram equipes trabalhando no Windows, MSN e Visual Studio.

O documento descreve as práticas de TDD usadas pelas equipes como fluxos de trabalho de minuto a minuto, bem como fluxos de trabalho no nível da tarefa ...

Há um capítulo sobre TDD com um estudo de caso no livro recente, "Making Software: O que funciona e por que acreditamos". Mas você pode ficar desapontado, pois, se bem me lembro, o estudo não descobriu nenhum benefício real para o TDD. De qualquer maneira, o estudo de caso foi interessante, e o livro em geral é um dos melhores livros de software que li recentemente. Ele contém muitos estudos de caso de coisas como programação de pares, revisão de código etc.

Definitivamente, verifique isso: TDD comprovadamente eficaz! Ou é?

... quando Phil Haack anunciou que a pesquisa apoia a eficácia do TDD, fiquei mais do que um pouco interessado em ver o que o relatório vinculado realmente continha. Phil cita o resumo.

Descobrimos que, em média, os alunos que realizaram o primeiro teste escreveram mais testes e, por sua vez, os alunos que escreveram mais testes tenderam a ser mais produtivos. Também observamos que a qualidade mínima aumentou linearmente com o número de testes do programador, independentemente da estratégia de desenvolvimento empregada.

Phil obviamente leu o restante do relatório e fornece suas peças favoritas que parecem fazer o que o título sugere. Uma das coisas com as quais me preocupo quando vejo que apóiam as melhores e mais recentes práticas de desenvolvimento de software é uma forte tendência ao viés de confirmação - de procurar confirmação das teorias atuais e ignorar os contra-indicadores.

Então, sendo do tipo curioso, e como TDD é algo que eu fico de olho para ver se é algo que eu gostaria de me adotar algum dia, entrei no relatório ...

... sem dúvida, o teste primeiro leva a mais testes por unidade funcional. A questão é se isso é valioso. Este estudo parece indicar que esse provavelmente não é o caso, pelo menos se a qualidade for o ganho pretendido. Mas não me surpreende que o número de testes não corresponda à qualidade, assim como não surpreende que o número de linhas de código não corresponda à produtividade.

O autor tem muitos pontos positivos sobre o TDD não ser tão eficaz (imo, apesar de estar exagerado)

veja quanto tempo você e o cliente gastaram testando manualmente o software; compare isso com uma estimativa de quanto tempo os testes automatizados no estilo TDD levariam. Pocket a diferença

na minha experiência, os testes automatizados do TDD são de ouro, porque oferecem seguro e eliminam enormes quantidades de testes manuais

como apontou Andres F, você pode obter esses benefícios apenas com testes automatizados, não necessariamente com TDD - no entanto, o TDD exige testes automatizados, em vez de ser uma reflexão tardia ou interessante.

Ser forçado a pensar em testar primeiro também obriga a pensar em questões relacionadas à qualidade - como modularidade, design de interface etc. - antes de começar a escrever o código.

Pessoalmente, acredito que um dos maiores benefícios do TDD é que escrever o teste primeiro mantém a especificação do que o código realmente precisa fazer em sua mente enquanto você está escrevendo o código, em vez de descobrir o que fazer -como você codifica.

você quer justificar isso: sugira que você faça isso para o próximo projeto e aprenda com ele. Se isso funcionar muito bem para você, espero que você continue a usá-lo e se demorou mais tempo para fazer o projeto e / ou gaste todo o seu tempo escrevendo testes em vez de codificar, certamente o despejará como uma falha.

Eu acho que a solução do mundo real é (como a maioria das coisas) a meio caminho, você quer testes, mas não quer que os testes sejam mais importantes que o projeto.

(pessoalmente, acho que o TDD é um modismo, soa bem em teoria, mas na prática ... não é tão bom. Acho que o teste de integração é muito mais importante, mas esse pode ser o tipo de projeto complexo em que trabalho).

A partir de agora, as empresas de transporte rodoviário de carga e de passageiros, que utilizam o TDD há mais de um ano, podem optar por não utilizar o TDD por até dois anos.

• Descobrindo bugs em um estágio inicial.
• Escrever código melhor sem nem perceber.
• Seu código agora é mais sustentável, pois, devido aos seus testes, todos os fragmentos são pequenos (tivemos funções que eram de 300 a 400 linhas). Agora no máximo 30 e todos testados indenpendentemente.

Os gerentes não saberiam, pois todos estão interessados ​​em uma coisa: "Você terminou". Mas eles reclamam quando o software continua quebrando sem perceber. Com uma boa cobertura e testes sensíveis, não é a quantidade, mas a qualidade que você pode ver quando alguém quebra uma funcionalidade. Infelizmente, também é difícil se você estiver sozinho. Eu tive o mesmo problema, pois pode ser necessário alterar o código, por exemplo, classes base etc., para que você possa testar partes do software.

Eu dou um exemplo. Eu queria zombar do repositório, mas não havia interface e preciso injetar o repositório na minha camada de serviço e, portanto, adicionar / modificar um construtor em toda a loja, isso acabou sendo um grande problema, mas em No final, tenho mais de 200 testes apenas testando uma área do sistema e eles ficaram impressionados.

Eu costumo fazer o seguinte:

• Eu mantenho minhas unittests muito curtas
• Apenas 1 afirmação. Nenhuma roleta russa.
• Testo um cenário positivo-negativo e de exceção

Com relação aos estudos de caso, receio, não tenho certeza de ter visto algum. Você precisa criar seu projeto e se tornar um estudo de caso. Eles também podem ficar impressionados.

Espero que ajude