TDD: Test Driven Development ou Desenvolvimento Guiado por Testes

Atualizado: Jan 29



TDD é o acrônimo de Test Driven Development, em tradução livre para português, Desenvolvimento Guiado por Testes, que nada mais é do que um processo de desenvolvimento de software baseado na repetição de um ciclo de desenvolvimento muito curto:





Red: escreva um Teste Unitário que, ao ser executado, irá falhar.

Green: implemente um código que seja suficiente para passar no teste unitário recém escrito.

Refactor: refatore o código, melhorando a leitura, eliminando redundância e adotando boas práticas.


Detalhando o TDD


O engenheiro de software americano Kent Beck, que é creditado por ter desenvolvido ou “redescoberto” a técnica, declarou em 2003 que o TDD incentiva projetos simples e inspira confiança.

A figura abaixo mostra com mais detalhes o Ciclo de vida global do TDD:




1. Adicione um teste


A implementação do teste irá forçar o desenvolvedor a conhecer as especificações e entender os requisitos, que podem ser obtidos através da leitura dos casos de uso.



2. Execute todos os testes e veja se o novo teste falha


Esse passo valida que os testes já escritos estão funcionando e mostra que o novo teste não está passando pelo motivo esperado: a funcionalidade ainda não foi implementada. Agora, temos um objetivo: fazer o teste passar!



3. Escreva o código


O próximo passo é escrever um código que faça com que o teste seja aprovado. O novo código não precisa ser perfeito e pode passar no teste de maneira deselegante, pois será aprimorado na etapa 5. Neste momento, o único objetivo do código é passar no teste. O código deve ser simples, seguindo os princípios KISS.



4. Rode os testes


Quando todos os testes passarem, o desenvolvedor terá certeza de que o novo código atende aos requisitos e não quebra nenhuma funcionalidade existente.



5. Refatore


O novo código pode ser movido de onde era conveniente estar para passar em um teste para o local onde ele logicamente pertence. Duplicações devem ser removidas. Os nomes de objetos, classes, módulos, variáveis ​​e métodos devem representar claramente seu objetivo e uso atuais. As hierarquias de herança podem ser reorganizadas. As classes devem ter uma única responsabilidade, seguindo o Single Responsibility Principle.


Repita


Começando um novo teste, o ciclo é repetido. O tamanho das etapas deve sempre ser pequeno, com apenas de 1 a 10 edições entre cada execução de teste. Se o novo código não atender rapidamente a um novo teste ou outros testes falharem, desfaça a alteração ou reverta o código ao invés de debugar excessivamente o código.



O que eu ganho com isso?


Entre os benefícios de se utilizar o TDD, podemos citar:

Rápido feedback sobre a funcionalidade recém implementada;

2. Código mais limpo e simples;

3. Segurança no refactoring e na correção de bugs, sabendo que se alguma funcionalidade não prevista for afetada, seu teste vai quebrar;

4. Maior produtividade não perdendo tempo com debug;

5. Menos tempo perdido em discussões com a equipe de Qualidade;

6. Possibilidade de Integração Contínua, com realização de builds e deploys automáticos.



Mas pra que fazer TDD se eu posso escrever o teste depois?


Para utilizar o TDD, o desenvolvedor precisa entender claramente os requisitos da funcionalidade e uma maneira de fazer isso é através da leitura do caso de uso.

Esta é a diferenciação entre Desenvolvimento Guiado por Testes e escrever testes unitários depois do código desenvolvido. Dessa forma, o desenvolvedor se obriga a focar nos requisitos antes de focar no código.

Além disso, se os testes unitários forem escritos após o desenvolvimento, você pode acabar não cobrindo todo o seu código, ou até deixar de implementar os testes unitários porque estará absorvido por uma nova demanda urgente.



Produtividade


A primeira coisa que vem em mente ao se conhecer o processo TDD é: "agora eu vou gastar boa parte do meu tempo escrevendo testes e vou demorar mais para entregar minhas tarefas!". Sim, você utilizará mais tempo e terá que escrever os tests unitários. Porém, isso não significa queda na produtividade.

Uma das vantagens podem ser observadas no TDD é a diminuição da necessidade de realizar debug no código, ou ainda, a diminuição da necessidade de procurar um problema lendo muitas linhas de código fonte. Ambas atividades são consumidoras ávidas de tempo de desenvolvimento. E após procurar, debugar e corrigir o seu código, em algum ponto no futuro um novo problema ocorrerá que exigirá que o código fonte seja novamente revisado e debugado. Isso é muito demorado e consequentemente, muito caro.

Além disso, se você realiza testes manuais, você repete o mesmo teste várias vezes por dia. Se você automatiza os seus testes, utiliza o seu tempo apenas uma vez.



Mas eu sei que o meu código funciona. Preciso mesmo criar testes unitários?


Testes unitários, assim como quaisquer outros testes automatizados, não tem como principal função verificar se uma função específica está funcionando. O verdadeiro valor dos testes unitários está em garantir que sua aplicação continue funcionando após a realização de alterações em seu código fonte.

Além disso, você deve lembrar que irá passar a maior parte do tempo de desenvolvimento de um sistema trabalhando em sua manutenção. Sua aplicação em pouco tempo terá centenas de funções sendo executadas, seu código fonte ficará grande rapidamente e logo será muito difícil testa-lo de forma manual após eventuais alterações. Testes unitários na maioria das vezes levam poucos segundos para testar toda sua aplicação.



Tá, me convenci. Que ferramentas devo utilizar?


Existem diversas ferramentas de testes unitários para cada linguagem de programação. A leitura da documentação dessas ferramentas é sempre um ótimo ponto de partida.

Caso você não conheça nenhuma ferramenta ou framework de testes automatizados, a SDC Labs e a AT.Info patrocinam uma lista com curadoria dessas ferramentas para várias linguagens de programação diferentes.



Referência


Test-driven development

Test-driven development ( TDD) is a software development process that relies on the repetition of a very short…

en.wikipedia.org


KISS principle

KISS, an acronym for " keep it simple, stupid" or " keep it stupid simple", is a design principle noted by the U.S…

en.wikipedia.org


Single responsibility principle

The single responsibility principle is a computer programming principle that states that every module, class, or…

en.wikipedia.org


TDD - O processo de automação com testes

Tempo de leitura: 5 minutos TDD (Test-Driven Development ou Desenvolvimento Orientado a Testes) tem se tornado sem…

www.eusoudev.com.br


Afinal, o que é TDD? - Blog da TreinaWeb

Durante o desenvolvimento de um software, é essencial aos desenvolvedores entregarem um software que funcione…

www.treinaweb.com.br


Entenda de uma vez por todas o que são testes unitários, para que servem e como fazê-los

Um certo dia, navegando por comunidades de desenvolvimento de software me deparei com a seguinte imagem:


medium.com


Leitura

https://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530

https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627

https://www.amazon.com/Test-Driven-Development-Practical-Guide/dp/0131016490

315 visualizações