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


14

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.


1
Na verdade, eu acho que "adicione testes de unidade e espero que o gerente não perceba que eles estão perdendo tempo" "é mais comum do que" adicione testes de unidade para atender às métricas do gerente ", mas acho que é por isso que alguns estudos de caso seriam bons.
Carson63000 #

1
Além disso, o TDD permite que você defina, desde o início do processo, quando será concluído, pois você tem todos os testes que devem passar.


@ user1249 O TDD não diz "escreva todos os testes antes de escrever qualquer código". Diz "escreva um único teste que falhe, e uma única coisa para fazê-lo passar; repita conforme necessário". Se você escrever todos os seus testes primeiro, perderá o ciclo de feedback apertado entre o código de teste e produção, que é um dos motivos para usar o TDD em primeiro lugar.
precisa saber é o seguinte

Respostas:


8

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 ...


6

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.


4

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)


Não tenho certeza de como posso postar mais do que o link sem duplicar o conteúdo vinculado? O artigo fornece o que o OP solicita: um estudo de caso sobre TDD e uma revisão desse estudo.
29713

4

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.


2
Concordo, mas também é importante observar que passar nos testes de unidade não significa que o software esteja correto, apenas que ele faz o que a unidade testa, exceto. Se o teste de unidade for incorreto, o software também poderá ter um erro. Se não for aprovado, o software pode estar correto, se o teste de unidade for com erros. É por isso que testes manuais também são necessários.
Tamás Szelei

1
O objetivo declarado do TDD não é reduzir o teste manual, mas melhorar o design. Testes automatizados são um conceito ortogonal ao TDD; você pode tê-los sem TDD.
Andres F.

@AndresF. você está certo; resposta editada
Steven A. Lowe

2

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).


2

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.