Test-driven Development
O test-driven development (TDD), ou Desenvolvimento orientado por testes, é uma abordagem em que a equipa desenvolve o produto ou serviço em resposta a testes. Ou seja, no TDD, os testes surgem primeiro que a implementação. Desse modo, este tipo de desenvolvimento é oposto ao tipo tradicional em que o projecto para desenvolver um produto ou serviço desenvolve-se primeiro e só depois criam-se os testes.
A ideia principal do test-driven development é que a equipa começa por criar testes unitários, antes de desenvolver o produto. Ou seja, os developers criam testes que demonstram como o produto deve funcionar com base nos requisitos. Em seguida, desenvolve o produto de forma a satisfazer apenas o teste, e faz os ajustes necessários para que funcione.
Além disso, o TDD é uma abordagem iterativa. Assim, o produto só se reformula se o teste falhar o que permite reduzir tempo, custos e duplicação de trabalho. Kent Beck criou o TDD nos anos 1990, como parte do XP (Extreme Programming). Desse modo, esta abordagem utiliza ciclos de desenvolvimento rápidos e repetitivos, a que normalmente se chama “Red-Green-Refactor”. Por fim, o TDD geralmente usa-se em combinação com outras técnicas como o refactoring.
Ciclo de Test-Driven Development “Red-Green-Refactor”
O ciclo “Red-Green-Refactor” é uma forma fácil de explicar o TDD. Vejamos, desse modo, em maior detalhe:
Fase Red
Nesta fase cria-se um teste para um comportamento que será implementado. Essa fase é chamada de “Red” porque o teste irá falhar. Naturalmente que o teste irá falhar porque nesta fase ainda não existe produto.
Contudo, como não existe nenhum produto, esta fase é muito desafiante. Dessa forma, a solução é criar o teste pensando como se o produto já existisse. Depois de falhar, é preciso definir um novo teste que funcione desta vez. Além disso, nesta fase é preciso também pensar no que é necessário e não no que se pensa ser necessário.
Fase Green
Nesta fase a equipa deve concentrar-se em encontrar a melhor solução e não a melhor forma de a implementar. Desse modo, neste ponto é preciso desenvolver o produto para satisfazer o primeiro teste. Uma vez passado o primeiro teste, a equipa deve concentrar-se em criar o próximo teste para falhar, e, dessa forma, continua a adicionar componente aos produto para ele passar. Contudo, o desenvolvimento do produto não tem de ser perfeito apenas tem de funcionar. Isto porque, na fase de refactoring o produto refina-se.
Fase Refactoring
Por fim, nesta fase a prioridade é melhor o desenvolvimento do produto. Ou seja, eliminar lixo e duplicações que sobrecarregam o produto e o tornam mais lento e ineficiente.
Vantagens do Test-driven Development
As vantagens do TDD são imensas no desenvolvimento de produtos e serviços. Algumas das vantagens são, por exemplo:
- Desenvolver produtos mais simples – O TDD foca-se numa pequena funcionalidade de cada vez. Ao escrever o teste primeiro, será fácil verificar. Ao seguir um processo TDD, o produto desenvolve-se de forma modular, sendo, desse modo, mais fácil de perceber, manter, testar e alargar.
- Ganhar flexibilidade – Ao desenvolver os produtos com TDD, usa-se um sistema modular, tornando, dessa forma, mais fácil futuras alterações ou modificações.
- Reduzir custos de desenvolvimento – Ao desenvolver produtos com TDD reduz-se os custos porque os produtos são mais fáceis de manter, tem maior qualidade, entre outros factores.
- Melhorar a qualidade – Em regra os produtos desenvolvidos com TDD têm qualidade mais alta, com menor bugs e são, desse modo, mais fáceis de manter.
- Melhorar a documentação – O plano de testes serve para demonstrar como o produto irá funcionar. Ao anexar-se ao produto mostra-se de forma fácil e estruturada como o produto funciona. Tornando simples qualquer mudança que seja preciso fazer.