Neste artigo, analiso algumas estatísticas e estudos sobre o desenvolvimento orientado por testes para compreender como tem sido utilizado, quais os seus benefícios e os desafios que as equipas enfrentam com esta abordagem.
Tradicionalmente, o processo de desenvolvimento de software decorre de forma linear. No entanto, nas últimas décadas, à medida que os sistemas ágeis se tornam mais populares (com até 87% das equipas a seguir uma abordagem ágil ou semelhante à ágil), o desenvolvimento de software começou a adotar diferentes metodologias que têm em conta os requisitos e as características do projeto.
A técnica de desenvolvimento orientado por testes (TDD) é um dos métodos que tem vindo a atrair atenção na área do desenvolvimento ágil de software.
Num artigo de investigação publicado pelo Instituto de Engenheiros Elétricos e Eletrónicos, os autores Yahya Rafique e Vojislav Misic afirmam que “o Desenvolvimento Orientado por Testes (TDD) está entre as práticas fundamentais do processo de desenvolvimento de Programação Extrema (XP)” (Fonte).
É referido que o homem a quem se atribui o desenvolvimento do TDD “afirmou, em 2003, que o TDD incentiva conceções simples e inspira confiança” (Fonte). No entanto, continuam a existir dúvidas relativamente às afirmações sobre produtividade e qualidade associadas ao TDD.
Reunimos algumas das estatísticas mais recentes sobre TDD para testar as afirmações apresentadas.
Este artigo começa por definir o conceito de TDD e explicar em que difere da abordagem tradicional. De seguida, analisamos algumas das estatísticas que validam ou rejeitam as afirmações feitas sobre o TDD.
O que é o desenvolvimento orientado por testes?
O desenvolvimento orientado por testes é uma abordagem em que um teste é escrito antes de o programador de software criar o código de produção necessário para o cumprir. A ideia fundamental desta técnica é permitir que o autor do código dedique algum tempo a ponderar a conceção ou os requisitos antes de escrever código funcional.
Processo de TDD
- Escrever o teste: No TDD, todas as novas funcionalidades começam com a escrita de um teste. O programador tem de compreender a especificação e os requisitos da funcionalidade. Para o fazer, terá de analisar histórias de utilizador e casos de utilização para compreender o objetivo do novo código que está a desenvolver.
- O teste falha: Depois de escrever o teste, o programador executa-o. Como ainda não existe código para o implementar, o teste irá falhar. Isto confirma que a estrutura de testes automatizados funciona corretamente e elimina a possibilidade de o novo teste passar sempre por estar defeituoso.
- Escrever o código: Agora, o programador sabe que a funcionalidade funciona de acordo com a conceção. Em seguida, escreve o código que faz o teste passar. O código pode não ser perfeito ou passar no teste de forma exemplar, mas isso não é relevante. Não se espera que o programador escreva código para além da funcionalidade que o teste foi criado para verificar.
- Executar os testes: Sabendo que a funcionalidade funciona conforme foi concebida, sempre que lançar código novo, o programador pode utilizar uma ferramenta de gestão de testes para executar novamente esse teste, obtendo a validação de que a atualização mais recente não danificou a funcionalidade anterior.
- Refatorar o código: No TDD, à medida que a base de código cresce, tem de ser continuamente limpa. Considerando que o principal objetivo do programador nas fases anteriores era apenas escrever o código, esta fase assegura a eficiência. Permite melhorar a estrutura interna do código-fonte do programa, preservando as suas características externas. Esta fase pode remover duplicações e adicionar novas funcionalidades.
- Repetir: Os passos acima são repetidos automaticamente para garantir que os ciclos de TDD abrangem todas as funcionalidades.
Have an account? Log In
Diferenças entre o TDD e o desenvolvimento tradicional
Para compreender o TDD, parece adequado determinar em que difere das abordagens tradicionais à programação.
A principal diferença é que os métodos tradicionais seguem um processo linear, enquanto o TDD segue um processo cíclico.
Os programadores que utilizam os métodos de teste tradicionais começam por criar o código e concentram-se apenas no teste no final do processo de desenvolvimento. Por outro lado, quem segue o modelo TDD começa por criar o teste e, em seguida, desenvolve o código que satisfaz o teste. Esta abordagem partilha muitos princípios com o movimento de antecipação dos testes no teste de software.
Embora o programador que utiliza a abordagem tradicional possa prestar atenção à correção do código, corre o risco de não detetar todas as falhas do código. O programador que utiliza o método TDD trabalha no código até este passar no teste, através da refatoração do código. Isto é feito até o código cumprir os requisitos funcionais, um processo suscetível de resultar em menos erros.
O TDD é mais lento ou mais rápido do que o desenvolvimento de testes tradicional?
Relativamente à questão de saber se o TDD torna o processo de programação mais rápido, existem estatísticas contraditórias provenientes de várias fontes.
Um estudo de caso que envolveu equipas de engenheiros de software da Microsoft e da IBM concluiu que as “equipas registaram um aumento de 15-35% no tempo de desenvolvimento inicial” quando utilizaram a técnica TDD. No entanto, o estudo salienta que estes são valores “estimados subjetivamente pela gestão” (Fonte).
Considerando que os estudos da Microsoft e da IBM indicam que houve melhorias na qualidade, pode argumentar-se que, a longo prazo, o TDD poupa o tempo que teria sido necessário para corrigir problemas. As equipas da Microsoft e da IBM concordaram com esta perspetiva (Fonte).
Um estudo centrado nas perceções iniciais de profissionais experientes ao utilizarem TDD conclui que “depois de ultrapassarem as dificuldades iniciais para compreender onde começar e saber como criar um teste para uma funcionalidade que ainda não existe, os participantes ganham maior confiança para implementar novas funcionalidades e fazer alterações devido à ampla cobertura de testes” (Fonte). O que isto parece sugerir é que as coisas melhoram com o tempo.
Num texto para a plataforma de publicação online Medium.com, o programador e autor de “Composição de Software” e “Programação de Aplicações JavaScript”, Erick Elliot centra-se na forma como o TDD mudou a sua vida. Elliot concorda que o processo pode ser lento no início, mas afirma: “por volta dos 2 anos, algo mágico começou a acontecer: comecei a programar mais depressa com testes unitários do que alguma vez tinha programado sem eles” (Fonte).
Parece que a utilização de TDD pode tornar as coisas mais lentas inicialmente. No entanto, se analisarmos a situação a longo prazo, o tempo poupado graças a um código de melhor qualidade pode compensar o tempo perdido no início. Além disso, é expectável que, à medida que os programadores se tornam melhores a utilizar TDD, consigam trabalhar mais depressa.
Existem também muitos outros fatores a considerar ao tentar medir o tempo necessário para obter um resultado de elevada qualidade. Para saber mais sobre este tema, ouça o episódio de Niall Lynch no podcast The QA Lead sobre a medição de T2Q (Tempo até à Qualidade).
O TDD resulta em menos erros?
Na discussão acima, uma das principais vantagens apresentadas do TDD é o facto de resultar em menos erros. Mas as estatísticas confirmam-no?
Os mesmos estudos que envolveram as equipas de engenharia da Microsoft e da IBM, referidos acima, concluíram que “a densidade de defeitos antes do lançamento dos quatro produtos diminuiu entre 40% e 90% em comparação com projetos semelhantes que não utilizaram a prática TDD.” Especificamente, as equipas da IBM registaram uma redução de 40% na densidade de defeitos, enquanto as da Microsoft registaram uma redução de 60-90% (Fonte).
As estatísticas do desenvolvimento orientado por testes sustentam a conclusão de que o TDD produz melhor qualidade?
Com base nos resultados de um estudo apresentado no Primeiro Simpósio Internacional da IEEE, realizado na Finlândia em 2007, Maria Siniaalto e Pekka Abrahamsson relatam que foi demonstrado que o TDD produz uma melhor qualidade do código quando comparado com software desenvolvido sem TDD (Fonte).
No seu artigo, Siniaalto e Abrahamsson citam um estudo realizado na China que concluiu que o TDD melhorou o acompanhamento dos processos e a estimativa de tarefas. O mesmo estudo conclui que “o TDD também promove o seguimento de práticas e diretrizes consistentes”. Isto resulta numa melhor qualidade, com menos defeitos. Além disso, as equipas que utilizaram TDD conseguiram corrigir os seus defeitos mais rapidamente (Fonte).
Um estudo realizado com programadores, com cerca de dez anos de experiência profissional (em média), para investigar as suas perceções ao utilizarem TDD, cita um programador que afirma: “O TDD ajudou-me a melhorar o código, tornando-o mais legível.” Outro participante refere que “o TDD permite uma maior facilidade de manutenção” (Fonte).
O TDD promove uma conceção mais simples?
Boby George e Laurie Williams, ambos a trabalhar no Departamento de Ciências Informáticas da Universidade Estatal da Carolina do Norte, realizaram uma experiência na qual 24 programadores foram divididos em dois grupos: um utilizou TDD e o outro utilizou a abordagem linear.
George e Williams referem que, entre os participantes, “92% dos programadores acreditavam que o TDD produz código de maior qualidade, 79% consideravam que o TDD promove uma conceção mais simples e 71% consideravam que a abordagem era claramente eficaz” (Fonte).
Estas estatísticas sobre o desenvolvimento orientado por testes relativas à qualidade constituem uma forte indicação de que o TDD resulta, de facto, num código de maior qualidade e numa conceção mais simples.
Num artigo publicado pelo portal de aprendizagem gratuito Guru99.com, Kanchan Kulkarni afirma: “O TDD torna o código mais simples e claro. Permite ao programador manter menos documentação” (Fonte).
É fácil adotar a conceção TDD?
Na experiência de George e Williams, 56% dos programadores profissionais consideraram difícil adotar uma mentalidade TDD, enquanto 23% afirmaram que a ausência de uma fase inicial de conceção era a razão dessa dificuldade. Do total de respostas, 40% consideraram difícil a adoção do TDD (Fonte).
Estas estatísticas sobre o desenvolvimento orientado por testes relativas à adoção indicam que o TDD é considerado difícil de adotar.
More Articles
O TDD é sobrevalorizado?
Num artigo publicado no Medium.com, Tylor Borgeson, que se descreve como programador de software de pilha completa interessado em aprendizagem automática, IA, infraestrutura, DevOps e metodologias ágeis, utiliza o título “O desenvolvimento orientado por testes é sobrevalorizado.” No entanto, o facto de ter colocado o título entre aspas demonstra que esta não é uma afirmação sua.
Borgeson aborda depois aqueles que afirmam que o método é sobrevalorizado e lento, dizendo-lhes que a maioria das pessoas que partilha esta opinião não utilizou o método durante tempo suficiente. Ao terminar o seu artigo, afirma: “Agora, pratique o desenvolvimento orientado por testes até deixar de ser doloroso” (Fonte).
O que se segue?
Aprenda abordagens de garantia de qualidade com especialistas no podcast The QA Lead
Subscreva o boletim informativo The QA Lead para receber os nossos guias práticos e episódios de podcast mais recentes
Inscreva-se na lista de espera do fórum da comunidade online The QA Lead, onde pode partilhar boas práticas com outros profissionais de garantia de qualidade e testes de software.
Esperamos vê-lo por lá!
