Obrigado a quem compareceu na apresentação! Os slides estão aqui!

Desvios comuns em TDD

View more presentations from mauricioaniche.

Qualquer dúvida, sugestão, crítica, por favor me mandem!

TDD é uma atividade de design. O teste de unidade que você escreve serve basicamente para definir suas expectativas em relação ao código que você vai escrever. E, ao fazer isso, você pensa não só no nível da implementação do algoritmo, mas em um nível um pouco mais alto: no nível de design. TDD permite que você brinque e experimente diferentes possíveis designs, dando feedback rápido sobre o resultado obtido, até que você encontre o design ideal para aquela situação.

Ou seja, quando você faz TDD, você pensa exclusivamente em design e não em testes. É uma prática de suporte para design de software.

Mas… É claro que você precisa testar! Você não apaga os testes que você produziu usando TDD, óbvio. Mas muito provavelmente eles não testam todas as possibilidades possíveis. E é aí que outras técnicas entram em cena, e você pode encontrar muita informação sobre elas em [1][2].

Resumindo, use TDD quando você precisa trabalhar no design de determinada classe ou módulo. Quando você estiver satisfeito com design, é hora de testar! Aí você pode fazer test-first, test-last, ou que você preferir, mas teste de verdade!

[1] The Art of Software Testing – Myers
[2] Introdução ao Teste de Software – Maldonado, Delamaro, Jino

O keynote foi feito pelo Steve Freeman, autor de um dos melhores livros de OO e TDD que já li (Growing Object-Oriented Software, Guided by Tests). Ele basicamente mostrou seu ponto de vista sobre TDD. Segundo ele, “programação comum está para TDD assim como programação procedural está para programação orientada à objetos”. Foco bem definido, bom feedback e progredir sem medo também foram citados como vantagens. Uma citação muito interessante, e que venho pensando há muito tempo sobre como transmitir essa idéia é a de que “o programador deve entender o porquê TDD funciona; caso contrário, é apenas burocracia”.

Em seguida, o aluno de mestrado Theodore Hellman nos apresentou a ferramenta que seu grupo desenvolve em Calgary, Canadá. Ela testa interfaces de uma maneira muito interessante: antes de desenvolver cada interface, o programador faz protótipos na ferramenta, desenhando caixas de texto, botões (parecidos com os que desenhamos no papel). A mágica acontece depois que o protótipo está pronto: você testa o protótipo, clicando nos botões e digitando valores nas caixas de texto fictícias, e a aplicação os executa na aplicação real! O problema é que funciona apenas para aplicações .NET Windows Forms.

Em seguida a apresentação do John Clements (um dos criadores do Dr. Scheme) e do David Janzen (professor da Politecnica da California, possui muitas publicações relacionadas a experimentos com TDD) sobre o quão difícil é ensinar TDD para os alunos. Apresentaram algumas técnicas de ensino e problemas que já tiveram nas primeiras aulas sobre o assunto.

O alemão Florian Barth, da Universidade de Manheim, mostrou a ferramenta para testes de aceitação que seu grupo trabalha. É uma mistura de Fitnesse com linguagem de programação, onde você escreve não só os casos de testes como a implementação do teste em planilhas. É bem interessante, já que basicamente elimina o trabalho de codificação dos testes. O problema é que algumas coisas ainda são um pouco complicadas e exigem um trabalho extra na planilha. Mas sem dúvida é um projeto para ficar de olho.

Robert Chatney apresentou seu framework LiFT, uma DSL para testes de aceitação em Java, inspirada no Cucumber. Ela faz com que seus testes em Java fiquem muito fluentes. Totalmente extensível, é um projeto que pretendo colaborar em breve. O código pode ser encontrado no Google Code.

Em seguida, apresentei meu paper sobre erros (ou desvios) que os programadores cometem quando praticam TDD. Apesar de algumas críticas em relação à metodologia (problemas esses que já eram conhecidos e estavam na seção de “ameaças a validar” do paper), as ideias ali foram elogiadas e todos concordaram com os problemas levantados pelo artigo. Lembrando que esse artigo é apenas um trabalho em andamento, parte da minha dissertação de mestrado. Espero postar partes dela em breve.

Chris Agmen-Smith apresentou sua experiência em um projeto real com ATDD, e fez questão de mostrar que é possível fazer ATDD sem grandes custos, mas com muitos benefícios.

No final do dia, Raj Mudhar solicitou ajuda para pesquisar na área de ATDD em projetos de grande porte. Qualquer empresa que tenha projetos grandes pode participar, divulgando seus dados e juntos publicarem os resultados em conferências de peso.

Resumindo, o evento foi muito muito bom. Um dia inteiro com riquíssimas discussões sobre as mais variadas pesquisas em TDD. Além disso, pude validar muitas ideias com pessoas realmente influentes na área. Um ponto muito interessante é que não estamos tão longe do que eles praticam no dia-a-dia, mas ainda temos um longo caminho a percorrer!

Até a TDD2011, em Berlin!

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.

You can find the survey at http://spreadsheets.google.com/viewform?formkey=dFlITDZfSTNkVmd5bEVQSFl4cTB3cHc6MA

I also twitted about it (http://twitter.com/mauricioaniche/status/7493800359), so it would nice if you re-tweet!

E o conteúdo? Devo dizer também que todas as palestras foram muito boas! O nível foi altíssimo e a plateia fez perguntas muito inteligentes em todas elas. Parabéns ao Giovanni Bassi, Juliano Oliveira, Vitor Cavalcante e Leandro Daniel pelas palestras.

A minha palestra sobre testes automatizados também foi legal, acho que consegui cumprir meu objetivo que era a de motivar todos a testar, e como diria Bryan Lyles, “test all the fucking time”! Obtive um feedback muito bom dos participantes, e fico feliz com isso, já que dessa maneira posso melhorar ainda mais a palestra para as próximas oportunidades.

Sobre os vídeos, eles serão publicados em breve. Os slides você pode ver no slideshare aqui.

Enfim, obrigado a todos os organizadores e a todos que foram ao evento. Ano que vem vai ser melhor ainda! Que venha o DNAD 2010!

As palestras estão muito boas, serão abordados DDD (Domain-Driven Design), Injeção de Dependência, ASP.NET MVC, ORMs (com NHibernate) e Testes Automatizados. Eu serei palestrante e falarei sobre testes automatizados!

O evento custa apenas R$ 50,00! Corra, as inscrições estão acabando!

Mais informações em http://www.dotnetarchitects.net/dnad2009