[DojoMoc] Artigo recomendado por Diego Caxito: TDD realmente ajuda?

[Diego Caxito]

Olá Agilidade Moc, DojoMoc,
O seu amigo, Diego Caxito, recomenda o artigo titulado 'TDD realmente ajuda?' a você.

Aqui está o seu comentário:
N/A

TDD realmente ajuda?
Enviado por Mauricio Aniche em 16/04/2010 (10:53) em Técnicas de Desenvolvimento de Software

Geralmente um programador que nunca praticou TDD tem essa dúvida: será que TDD realmente ajuda na qualidade do código? E na redução de defeitos? Ele aumenta ou diminui a produtividade, afinal? Mas como toda e qualquer prática em engenharia de software, é muito difícil avalia r e chegar a uma conclusão exata sobre seus ganhos e benefícios.

Nos últimos anos, a comunidade acadêmica vem rodando diversos experimentos para tentar mostrar de maneira empírica que TDD realmente ajuda no processo de desenvolvimento de software. Alguns desses estudos são feitos por professores bastante conhecidos na comunidade, como a prof. Laurie Williams (North Carolina State University) e o prof. David Janzen (California Polytechnic State University).

Algumas dessas pesquisas investigam o fato de TDD reduzir o número de defeitos de um software; já outros investigam o fato de TDD produzir código de melhor qualidade. Alguns até pesquisam por indícios de aumento de produtividade.

Estudos na indústria

Janzen [5] mostrou que programadores usando TDD na indústria produziram código que passaram em aproximadamente 50% mais testes caixa-preta do que

o código produzido por grupos de controle que não usavam TDD. Além do mais, o grupo que usava TDD gastou menos tempo debugando. Janzen também mostrou que a complexidade dos algoritmos era muito menor e a quantidade e cobertura dos testes era maior nos códigos escritos com TDD.

Um estudo feito pelo Maximillien e Williams [6] mostrou uma redução de 40-50% na quantidade de defeitos e um impacto mínimo na produtividade quando programadores usaram TDD.

Outro estudo feito por Lui e Chan [7] comparando dois grupos, um utilizando TDD e o outro escrevendo testes apenas após a implementação, mostrou uma redução significante no número defeitos. Além do mais, os defeitos que foram encontrados eram corrigidos mais rapidamente pelo grupo que utilizou TDD. O estudo feito por Damm, Lundberg e Olson [8] também mostra uma redução significante nos defeitos.

O estudo feito por George e Williams[9] mostrou que, apesar de TDD poder reduzir inicialmente a produtividade dos desenvolvedores mais inexperientes, o código produzido passou entre 18% a 50% mais em testes caixa-preta do que códigos produzidos por grupos que não utilizavam TDD. Esse código também apresentou uma cobertura entre 92% a 98%. Uma análise qualitativa mostrou que 87.5% dos programadores acreditam que TDD facilitou o entendimentos dos requisitos e 95.8% acreditam que TDD reduziu o tempo gasto com debug. 78% também acreditam que TDD aumentou a produtividade da equipe. Entretanto, apenas 50% acreditam que TDD ajuda a diminuir o tempo de desenvolvimento. Sobre qualidade, 92% acreditam que TDD ajuda a manter um código de maior qualidade e 79% acreditam que ele promove um design mais simples.

Nagappan [12] mostrou um estudo de caso na Microsoft e na IBM e os resultados indicaram que o número de defeitos de quatro produtos diminuir entre 40% a 90% em relação à projetos similares que não usaram TDD. Entretanto, o estudo mostrou também TDD aumentou o tempo inicial de desenvolvimento entre 15% a 35%.

Langr [10] mostrou que TDD aumenta a qualidade código, provê uma facilidade maior de manutenção e ajuda a produzir 33% mais testes comparados a abordagens tradicionais.

Estudos na academia

Um estudo feito por Erdogmus et all [11] com 24 estudos de graduação mostrou que TDD aumenta a produtividade. Entretanto nenhuma diferença de qualidade no código foi encontrada.

Outro estudo feito por Janzen[13] com três diferentes grupos de alunos (cada um deles usando uma abordagem diferente: TDD, test-last, sem testes), mostrou que o código produzido pelo time que fez TDD usou melhor conceitos de orientação a objetos e as responsabilidades foram separadas em 13 diferentes classes enquanto que os outros times produziram um código mais procedural. O time de TDD também produziu mais código e entregou mais features. Os testes produzidos por esse time teve duas vezes mais asserções que os outros e cobriu 86% mais branches do que o time test-last.  Além do mais, as classes testadas tinham valores de acoplamento 104% menor do que as classes não testadas e os métodos eram, na média, 43% menos complexos do que os não-testados.

O estudo de Müller e Hagner [17] mostrou que TDD não resulta em melhor qualidade ou produtividade. Entretanto, os estudantes perceberam um melhor reuso dos códigos produzidos com TDD.

Steinberg [15] mostrou que código produzido com TDD é mais coeso e menos acoplado. Os estudantes também reportaram que os defeitos eram mais fáceis de serem corrigidos.

O estudo do Edwards [16] com 59 estudantes mostrou que código produzido com TDD tem 45% menos defeitos e faz com que o programador se sinta mais a vontade com ele.

Conclusão

A maioria dos experimentos feitos tanto na indústria quanto na academia mostram que TDD melhora o processo de desenvolvimento de software, aumentando a qualidade do código, reduzindo o número de defeitos, diminuindo o tempo gasto com depuração e até aumentando a produtividade dos desenvolvedores.

Entretanto, mais experimentos devem ser conduzidos, levando em consideração diferentes fatores de influência que existem em um ambiente de desenvolvimento de software.

Referências

Podem ser encontradas aqui.

Post original em http://www.aniche.com.br/2010/04/tdd-realmente-ajuda/

Geralmente um programador que nunca praticou TDD tem essa dúvida: será que TDD realmente ajuda na qualidade do código? E na redução de defeitos? Ele aumenta ou diminui a produtividade, afinal? Mas como toda e qualquer prática em engenharia de software, é muito difícil avaliar e chegar a uma conclusão exata sobre seus ganhos e benefícios.

Nos últimos anos, a comunidade acadêmica vem rodando diversos experimentos para tentar mostrar de maneira empírica que TDD realmente ajuda no processo de desenvolvimento de software. Alguns desses estudos são feitos por professores bastante conhecidos na comunidade, como a prof. Laurie Williams (North Carolina State University) e o prof. David Janzen (California Polytechnic State University).

Algumas dessas pesquisas investigam o fato de TDD reduzir o número de defeitos de um software; já outros investigam o fato de TDD produzir código de melhor qualidade. Alguns até pesquisam por indícios de aumento de produtividade.

Estudos na indústria

Janzen [5] mostrou que programadores usando TDD na indústria produziram código que passaram em aproximadamente 50% mais testes caixa-preta do que

o código produzido por grupos de controle que não usavam TDD. Além do mais, o grupo que usava TDD gastou menos tempo debugando. Janzen também mostrou que a complexidade dos algoritmos era muito menor e a quantidade e cobertura dos testes era maior nos códigos escritos com TDD.

Um estudo feito pelo Maximillien e Williams [6] mostrou uma redução de 40-50% na quantidade de defeitos e um impacto mínimo na produtividade quando programadores usaram TDD.

Outro estudo feito por Lui e Chan [7] comparando dois grupos, um utilizando TDD e o outro escrevendo testes apenas após a implementação, mostrou uma redução significante no número defeitos. Além do mais, os defeitos que foram encontrados eram corrigidos mais rapidamente pelo grupo que utilizou TDD. O estudo feito por Damm, Lundberg e Olson [8] também mostra uma redução significante nos defeitos.

O estudo feito por George e Williams[9] mostrou que, apesar de TDD poder reduzir inicialmente a produtividade dos desenvolvedores mais inexperientes, o código produzido passou entre 18% a 50% mais em testes caixa-preta do que códigos produzidos por grupos que não utilizavam TDD. Esse código também apresentou uma cobertura entre 92% a 98%. Uma análise qualitativa mostrou que 87.5% dos programadores acreditam que TDD facilitou o entendimentos dos requisitos e 95.8% acreditam que TDD reduziu o tempo gasto com debug. 78% também acreditam que TDD aumentou a produtividade da equipe. Entretanto, apenas 50% acreditam que TDD ajuda a diminuir o tempo de desenvolvimento. Sobre qualidade, 92% acreditam que TDD ajuda a manter um código de maior qualidade e 79% acreditam que ele promove um design mais simples.

Nagappan [12] mostrou um estudo de caso na Microsoft e na IBM e os resultados indicaram que o número de defeitos de quatro produtos diminuir entre 40% a 90% em relação à projetos similares que não usaram TDD. Entretanto, o estudo mostrou também TDD aumentou o tempo inicial de desenvolvimento entre 15% a 35%.

Langr [10] mostrou que TDD aumenta a qualidade código, provê uma facilidade maior de manutenção e ajuda a produzir 33% mais testes comparados a abordagens tradicionais.

Estudos na academia

Um estudo feito por Erdogmus et all [11] com 24 estudos de graduação mostrou que TDD aumenta a produtividade. Entretanto nenhuma diferença de qualidade no código foi encontrada.

Outro estudo feito por Janzen[13] com três diferentes grupos de alunos (cada um deles usando uma abordagem diferente: TDD, test-last, sem testes), mostrou que o código produzido pelo time que fez TDD usou melhor conceitos de orientação a objetos e as responsabilidades foram separadas em 13 diferentes classes enquanto que os outros times produziram um código mais procedural. O time de TDD também produziu mais código e entregou mais features. Os testes produzidos por esse time teve duas vezes mais asserções que os outros e cobriu 86% mais branches do que o time test-last.  Além do mais, as classes testadas tinham valores de acoplamento 104% menor do que as classes não testadas e os métodos eram, na média, 43% menos complexos do que os não-testados.

O estudo de Müller e Hagner [17] mostrou que TDD não resulta em melhor qualidade ou produtividade. Entretanto, os estudantes perceberam um melhor reuso dos códigos produzidos com TDD.

Steinberg [15] mostrou que código produzido com TDD é mais coeso e menos acoplado. Os estudantes também reportaram que os defeitos eram mais fáceis de serem corrigidos.

O estudo do Edwards [16] com 59 estudantes mostrou que código produzido com TDD tem 45% menos defeitos e faz com que o programador se sinta mais a vontade com ele.

Conclusão

A maioria dos experimentos feitos tanto na indústria quanto na academia mostram que TDD melhora o processo de desenvolvimento de software, aumentando a qualidade do código, reduzindo o número de defeitos, diminuindo o tempo gasto com depuração e até aumentando a produtividade dos desenvolvedores.

Entretanto, mais experimentos devem ser conduzidos, levando em consideração diferentes fatores de influência que existem em um ambiente de desenvolvimento de software.

Referências

Podem ser encontradas aqui.

Post original em http://www.aniche.com.br/2010/04/tdd-realmente-ajuda/

Artigo retirado do Tecnologia de Internet (Locaweb) - http://tecblog.locaweb.com.br
Endereço do artigo: http://tecblog.locaweb.com.br/2010/04/16/tdd-realmente-ajuda/

[Herberth Amaral]

Muito se fala hoje sobre TDD, mas TDD é só a ponta do Iceberg.

TDD diz respeito à testes unitários, mas há outros testes que se pode fazer antes. Já pensou em pedir seu cliente para fazer testes para você? Pois é, essa é a premissa dos testes de aceitação automatizados. Algumas ferramentas para tal são: Fit e Fitnesse.

Nele o cliente coloca os cenários de uso de um caso de uso e a ferramenta de testes de aceitação testa estas especificações no sistema. Para mais detalhes sobre o Fitnesse (uma versão mais colaborativa do Fit), visite: http://fitnesse.org/

2010/4/17 Diego Caxito <diego...@gmail.com>

--
Herberth Amaral
http://herberthamaral.com

[Diego Caxito]

O seu cliente realmente configura o fitnesse para os testes de aceitação dele?

2010/4/17 Herberth Amaral <herbert...@gmail.com>

--
Diego Caxito

[Luciano Soares]

Qual a complexidade de configuração e utilização dele pelo cliente?

[Diego Caxito]

Você está introduzindo para seu cliente a utilização de uma nova ferramenta. Quando a preocupação dele tem que ser e deve ser no processo apresentar e junto com a equipe chegar a um "acordo" daquilo que ele quer no final.

Além de que uma simples descrição em escrito ou durante conversas com seu cliente você consegue determinar as características que descrevem aquilo que ele irá aceitar ao final de sua iteração.

Antes que comecem, não contra, nem quero aqui questionar a ferramenta. Acho o Fitnesse uma excelente ferramenta para automatizar esse processo de teste, assim como o Selenium e outras por ae no mercado. Afinal cansa e muito ter que ficar dando build, rodar sua aplicação e começar a dar clique por clique para determinar se houve aceitação da sua funcionalidade pronta ao final.

Sim, TDD é apenas a ponta do Iceberg. Assim junto com tudo isso vem toda a implementação por traz de sua aplicação e do resultado desejado. Muitos outros fatores podem afetar e interferir nesse meio. Como: O domínio utilizado por você e por sua equipe é o mesmo que o interessado no resultado, cliente, usa? Sua arquitetura reflete esse domínio? Seu código reflete esse domínio?

Voltando ao foco do artigo.TDD ajuda em muito e quem aplica em produção sente logo alguns sintomas disso:

- No início a quebra de paradgma de desenvolvimento é muito grande.

- Sua velocidade de entrega vai diminuir até acostumar com tudo.

Porém.

- A qualidade do Design de sua aplicação cresce extremamente.

- Ver coisas como o sinal vermelho e seus testes, refatorar, depois ver o sinal verde indicando que seu teste passou e que o código que você escreveu está comprovadamente testado e passando sem problemas, não tem preço.

- Seu código vai "refletir" mais claramente aquilo que foi desejado.

- A qualidade do código, lógico que aplicando devidamente as técnicas de refactoring, vai aumentar e muito.

- O tempo "perdido" no início vai ser completamente compensado no final, quando aparecer um bug e você corrigí-lo com mais um teste, sem ter que ficar desesperadamente aquela ">" a mais que você esqueceu em um "if" ou o lugar de uma conversão de dados mau feita.

- A quantidade de bugs que vai aparecer no final do processo é extremamente reduzida.

- Por final de tudo isso, você evita todo aquele disperdício de tempo com manutenção de código legado. Aliás, se você tiver um que não está sobre Unidades de Testes, você acaba desconfiando ao extremo dele, escreve os códigos de teste e agora no mínimo garante uma cobertura descente.

Por fim, TDD não substitui nenhuma técnica de engenharia de software ou de testes existente, mas sem dúvida alguma é "Up to next level" eu seu código e na qualidade de sua aplicação.

2010/4/17 Luciano Soares <luss...@gmail.com>

--
Diego Caxito

[Herberth Amaral]

Sim. O que seu cliente tem que fazer é descrever os cenários de um caso de uso em uma tabela no Wiki. O Fitnesse é mais complicado por causa disso: ele usa um wiki. Mas ele tem a enorme vantagem de ser colaborativo.

Já com o Fit, você pode usar o Word mesmo (pra gerar HTML. Os dados são lidos das tabelas que descrevem o cenário e testados no software). Só que aí a colaboração diminui. Assim, nada que impeça do cara usar o Docs ou alguma outra ferramenta de colaboração, mas isso "dificulta" um pouco o processo.

Como toda ferramenta, ela precisa de um treinamento básico. Mas, assim como TDD, há várias histórias de sucesso. O Uncle Bob de vez em quando retuíta umas (ele é o mantenedor do Fitnesse).

2010/4/17 Diego Caxito <diego...@gmail.com>