< Insights

O que é Test-Driven Development (TDD)?

  • Testes Automatizados
  • Artigo

O Test-Driven Development (TDD) é o Desenvolvimento Orientado por Testes, em que é possível desenvolver o próprio software com base em alguns testes escritos antes dos códigos de produção.

A ideia desse desenvolvimento orientado por testes é antiga e foi afirmada pelo autor do famoso livro “Test Driven Development: By Example ”, Kent Beck. Ao longo da matéria, você verá melhor o que é e o que significa TDD, qual sua importância e benefícios para os testes automatizados, quando não usá-lo e as principais diferenças entre as técnicas de desenvolvimento TDD e Behavior Driven Development (BDD), que prioriza os testes de código. Continue a leitura e saiba mais sobre o tema!

O que é TDD?

O TDD é uma técnica de desenvolvimento que prioriza os testes de códigos baseada em pequenos ciclos de repetições, em que antes é criado um teste para cada funcionalidade do sistema.

Este novo teste criado do qual estamos falando precisa apresentar uma falha inicialmente, visto que ainda não há a implementação necessária da funcionalidade em questão. A partir disso, implementa-se a funcionalidade para que o teste possa passar.

Não se deve interromper o ciclo escrevendo outro teste apenas pelo fato de já ter um teste passando. A funcionalidade escrita ainda precisa ser refatorada, ou seja, ela precisa garantir boas práticas de desenvolvimento de software para o resultado de um código mais limpo e menos acoplado.

O ciclo de desenvolvimento do TDD se baseia em três etapas: escrever um teste que inicialmente falhará, adicionar uma funcionalidade para que o teste passe e refatorar o código da nova funcionalidade para que o próximo teste possa ser escrito.

Nessa estratégia, obtém-se um feedback tão rápido quanto a nova funcionalidade e uma possível falha de outra dentro do sistema. Sendo assim, surge muito mais segurança para os processos de refatorações e na adição de novas funcionalidades.

A principal característica que se destaca em meio à técnica do TDD é sua simplicidade. A principal regra é o seu ciclo de desenvolvimento: a criação de um teste que falhe, escrever um código para que o teste passe e em seguida refatorá-lo.

O TDD pode ser extremamente útil ao lidar com problemas de programação mais complexos, mas é possível, em alguns casos, deixá-lo de lado ao resolvermos as ferramentas mais simples.

Qual a importância e os benefícios do TDD para os testes automatizados?

O TDD é mais utilizado nos processos ágeis e mais complexos, mas ele também pode ser aplicado em outras metodologias tradicionais.

Sua técnica de desenvolvimento auxilia no entendimento do software para que suas regras fiquem bem claras antes mesmo de iniciar o processo de codificação, trazendo simplicidade e confiança para o código produzido.

O TDD fornece vários benefícios ao desenvolvimento de software, a exemplo dos feedbacks mais rápidos sobre as novas funcionalidades, como já citado anteriormente. Ele também gera um código mais limpo, visto que são escritos esses códigos mais simples a fim de fazer o teste passar.

Além disso, oferece segurança no processo de refatoração do ciclo de desenvolvimento, possibilitando a visão do que estamos ou não afetando, e segurança na correção de bugs.

O TDD traz uma maior produtividade justamente pelo fato de o desenvolvedor encontrar menos bugs, o que não desperdiça seu tempo com depuradores. O código da aplicação se torna mais flexível, visto que para escrevê-los, precisamos separar o nosso código em pequenas partes, para que sejam testáveis.

Quando não usar o TDD?

Há um questionamento por trás do uso do Test-Driven Development. Será que é mesmo preciso usar o TDD em todos os casos de programação? 

O TDD é a evolução da sua lógica e do algoritmo que está sendo criado, obtendo feedbacks através deles – o que agrega bastante seu valor. Se você sabe qual é a solução mais genérica possível para aquele problema e este não necessita de uma documentação detalhada sobre seu funcionamento, por ser facilmente compreendido por quem o enfrenta, não perca tempo e parta logo para a solução, afinal o que conta é a simplicidade do seu processo.

Em situações como essa, caso você já tenha conhecimento de qual caminho seguir, é possível sim deixar o Test-Driven Development de lado e não usá-lo, partindo direto para essa lógica.

Busca-se escrever testes para vários métodos, inclusive para os muito simples, como getters e setters. Portanto, não há a necessidade de escrever um teste automatizado para esses métodos, justamente por eles serem muito simples, são linhas de programação que não agregam nenhum valor para o produto final.

Ainda assim, é preciso estar atento à seguinte afirmação: “Regra simples não precisa de teste automatizado”. Essa ideia é incompleta, pois quando nos referimos a isso, estamos falando de simplicidade de código, códigos muito simples, como os citados getters e setters – geralmente, de uma ou duas linhas.

Alguns dos erros mais comuns na prática do TDD é escrever esses testes e não enxergar suas respectivas falhas. Dê atenção aos testes que falham, ao aplicar o TDD e não obter nenhum resultado de falha no teste, suspeite de que há algo de errado.

Sugerimos adotar o TDD para correção de bugs. O bug é por natureza um cenário do sistema que falha. Então, replicá-lo por meio de testes automatizados é uma atividade bem natural para o desenvolvedor. 

Qual a diferença entre Test-Driven Development e Behavior Driven Development?

O Test-Driven Development, como o prório nome diz, se trata de um desenvolvimento orientado a testes, enquanto o Behavior Driven Development (BDD) é um desenvolvimento orientado para os comportamentos.

Ambas técnicas são de desenvolvimentos que têm como objetivo priorizar os testes de código, desenvolvimento ágil e integração contínua.

Tanto o TDD quanto o BDD são desenvolvimentos orientados a testes, mas com uma diferença: em TDD, você é responsável por escrever os testes e validá-los de forma que eles funcionem. Já em BDD, você escreve como o problema deve se comportar – é mais humano do que os testes.

O BDD contribui para integrar as diferentes áreas de uma empresa, definir como uma demanda chega ao desenvolvedor e pensar, partindo do comportamento esperado de uma funcionalidade. Isso acaba influenciando no planejamento e em como são escritos os testes.

Por fim, o BDD e o TDD são métodos possíveis de serem aplicados em conjunto ou com apenas um deles – um não vai contra o outro. Ambas técnicas tem como finalidade melhorar o desenvolvimento de software. A Objective trabalha fortemente com a cultura de Testes Automatizados e indicamos para sua empresa investir em testes automatizados dentro do seu processo de desenvolvimento de software. Em pouco tempo, você colherá os frutos dessa importante decisão: aumento da qualidade da entrega, aumento da previsibilidade, segurança para refactoring, redução de custos e aumento da satisfação dos clientes.

Insights do nosso time

Obtenha insights do nosso time de especialistas sobre metodologias de desenvolvimento de software, linguagens, tecnologia e muito mais para apoiar o seu time na operação e estratégia de negócio.