TDD: Como aplicar desenvolvimento orientado a testes

O Desenvolvimento Orientado a Testes, ou TDD (Test-Driven Development), é uma técnica de programação onde você escreve os testes automatizados antes de criar o código funcional

Como aplicar TDD na prática exige um plano de evolução por níveis de maturidade não uma lista solta de dicas. Times que aprendem só a teoria do ciclo Red-Green-Refactor costumam travar assim que o Test-Driven Development precisa lidar com regras de negócio complexas, código legado ou uma arquitetura de microsserviços.

Este guia reúne, em um único lugar, o caminho de aprendizado que a Codurance recomenda para desenvolvimento orientado a testes: do nível iniciante (fundamentos e primeiras katas) ao nível avançado (TDD aplicado a arquitetura e sistemas distribuídos), passando pelo nível intermediário, em que o time aprende a refatorar com confiança, integrar TDD ao pipeline de CI/CD e introduzir testes automatizados em código legado.

O que vamos explorar sobre como aplicar TDD:

• O que é TDD e por que aplicar no desenvolvimento de software?
• Como funciona o ciclo Red-Green-Refactor?
• Quais são as 3 leis do TDD?
• Como aplicar TDD no nível iniciante?
• Como aplicar TDD no nível intermediário?
• Como aplicar TDD no nível avançado?
• Quais são os antipadrões mais comuns ao aplicar TDD?
• Quais boas práticas mantêm os testes de TDD sustentáveis?
• TDD realmente reduz a produtividade do time?
• Quais ferramentas usar para TDD, por linguagem?
• Perguntas frequentes

O que é TDD e por que aplicar no desenvolvimento de software?

TDD (Test-Driven Development, ou Desenvolvimento Orientado a Testes) é uma prática de engenharia em que o teste automatizado é escrito antes do código de produção, guiando o design da solução em vez de apenas validá-la depois de pronta.

Aplicado de forma correta, o guia de TDD da Codurance descreve a prática como um caminho para tornar o desenvolvimento mais ágil e sustentar soluções de qualidade que escalam.

Os benefícios mais associados ao uso consistente de TDD:

• Design mais simples: só se escreve o código necessário para o teste passar.
• Rede de segurança para refatorar sem medo de quebrar comportamento existente.
• Documentação viva: os testes descrevem o comportamento real do sistema.
• Feedback em segundos, não em ciclos de QA manual ou homologação.

Como funciona o ciclo Red-Green-Refactor?

O ciclo Red-Green-Refactor funciona em três passos curtos e repetidos: escrever um teste que falha, escrever o código mínimo para ele passar, e só então melhorar a estrutura do código sem alterar seu comportamento.

Quais são as 3 leis do TDD?

As três leis do TDD definem os limites de cada micro-ciclo e mantêm o desenvolvimento sempre em passos curtos:

1. Não se escreve código de produção sem antes escrever um teste automatizado que falhe.
2. Não se escreve mais do que um teste unitário suficiente para falhar erro de compilação já conta como falha.
3. Só se escreve código de produção suficiente para fazer esse único teste que falha passar.

Para aprofundar esses conceitos, Test-Driven Development: By Example, de Kent Beck, é a referência clássica indicada pela Codurance para quem está começando o livro guia o leitor na construção de software de qualidade de forma iterativa, através de exemplos práticos.

Como aplicar TDD no nível iniciante?

No nível iniciante, o objetivo é entender a teoria por trás do TDD e praticar o ciclo Red-Green-Refactor em exercícios pequenos e isolados, antes de aplicá-lo em um projeto real.

Passo a passo recomendado:

1. Fixe a teoria antes de codificar: entenda o que é TDD, seus benefícios e em que ele difere de outras formas de desenvolver software.
2. Pratique com katas de programação, exercícios práticos que desenvolvem a habilidade através de repetição e reflexão comece pelos mais simples, focados só no ciclo Red-Green-Refactor.
3. Repita as mesmas katas várias vezes até sentir o ritmo do ciclo se tornar natural.
4. Refatore mesmo quando o código já funciona pular essa etapa é o erro mais comum de quem está começando.

Katas recomendadas para começar:

• String Calculator: escrever testes para uma calculadora simples que soma, subtrai, multiplica e divide.
• FizzBuzz: escrever um programa que imprime números de 1 a 100 com restrições específicas clássicas para praticar o ritmo do ciclo.

Depois de se sentir confortável com o básico, o próprio caminho de aprendizado da Codurance recomenda avançar para katas com um pouco mais de complexidade, como um simulador de caixa eletrônico ou um carrinho de compras na ponte natural para o nível intermediário.

Como aplicar TDD no nível intermediário?

No nível intermediário, o foco muda de exercícios isolados para o domínio de técnicas de refatoração, a aplicação de TDD em código legado e a integração da prática ao pipeline de CI/CD.

Katas de nível intermediário

• Caixa eletrônico (ATM): simula depósitos, saques e transferências, exigindo controle de estado.
• Carrinho de compras: modela o carrinho de um supermercado online, com múltiplas regras de negócio.
• Geladeira inteligente, Sudoku e Mars Rover: katas de nível médio que forçam decisões de arquitetura e design desde o início da implementação.

Domínio de refatoração

Entender quando e como refatorar sem alterar o comportamento do sistema é central nesta fase. Refactoring: Improving the Design of Existing Code, de Martin Fowler, é a referência mais indicada para aprofundar o assunto embora não seja um livro só sobre TDD, a refatoração é parte central do ciclo. Vale também acompanhar os artigos de Sandro Mancuso, cofundador da Codurance, sobre a relação entre TDD e design de software.

Como integrar TDD a pipelines de CI/CD?

TDD se conecta naturalmente a pipelines de integração contínua porque os testes escritos no ciclo Red-Green-Refactor são os mesmos que validam cada build antes do deploy.

1. Automatize a execução dos testes escritos seguindo TDD como parte do pipeline de CI.
2. Rode a suíte a cada commit, garantindo que nenhuma mudança quebre a funcionalidade existente.
3. Configure fail fast: o pipeline para assim que um teste falha, dando feedback rápido ao time.
4. Condicione o deploy ao sucesso dos testes e automatize a entrega para os ambientes de teste, staging e produção.
5. Implemente rollback automático para reverter rapidamente caso o deploy cause problemas na produção.

Ferramentas como Jenkins, GitLab CI/CD, CircleCI e GitHub Actions oferecem os plugins necessários para automatizar esse fluxo em torno de TDD.

Como aplicar TDD em código legado?

Introduzir testes em código legado é um dos maiores desafios do nível intermediário e uma das habilidades mais valiosas para quem trabalha em sistemas que já existem.

1. Identifique as áreas críticas: partes do código essenciais para o funcionamento da aplicação ou com alta taxa de erro entram primeiro.
2. Mapeie as dependências que dificultam o teste, usando ferramentas de análise de código para entender como isolá-las ou substituí-las por dublês.
3. Comece por testes de alto nível (integração ou aceitação) antes de partir para testes unitários, garantindo a funcionalidade básica do sistema antes de refatorar internamente.
4. Escreva testes de caracterização para documentar o comportamento atual do sistema antes de qualquer alteração.
5. Avance em incrementos pequenos, garantindo que cada mudança passe em todos os testes existentes antes de seguir para a próxima.

Michael Feathers, em Working Effectively with Legacy Code, e Martin Fowler, em Refactoring, são as referências mais citadas pela Codurance para consolidar essas técnicas.

O mesmo diagnóstico que orienta por onde começar a testar um legado quais módulos concentram risco e conhecimento crítico é o que o SQA entrega automaticamente pelos pilares Code Quality e Knowledge Distribution.

Como aplicar TDD no nível avançado?

No nível avançado, TDD deixa de ser uma técnica de escrita de testes e passa a orientar decisões de arquitetura, incluindo como o sistema se integra a serviços externos e microsserviços.

TDD e arquitetura de software

Robert C. Martin (Uncle Bob), em seu artigo "TDD Harms Architecture", oferece uma perspectiva crítica sobre como o TDD pode influenciar para o bem ou para o mal as decisões arquiteturais de um sistema. O livro Clean Architecture, do mesmo autor, é indicado pela Codurance como guia para integrar TDD a princípios de arquitetura limpa.

TDD em sistemas distribuídos e microsserviços

Aplicar TDD ao desenvolvimento de microsserviços exige estratégias próprias para lidar com comunicação assíncrona e propagação de dados entre serviços. Building Event-Driven Microservices, de Adam Bellemare, é uma leitura recomendada para entender como os dados são gerados e propagados nesse tipo de arquitetura.

Katas avançadas

• Bank kata: cria um sistema de contas bancárias com requisitos complexos a série sobre Outside-In TDD de Sandro Mancuso é indicada como apoio para resolvê-la.
• Corporate Hotel Booking: desenvolve um sistema de reservas para hotéis corporativos, atendendo três tipos diferentes de usuário.
• Roman Numerals: exercício que refina o processo de decisão sobre como e quando adicionar novos testes.

Ferramentas e frameworks avançados

Nesta fase, vale dominar frameworks de mock mais sofisticados, ferramentas de cobertura de código e sistemas de integração contínua especializados como Mockito (Java), Sinon.js (JavaScript) e pytest com Mock (Python).

Aprendizado contínuo e comunidade

• Global Day of Coderetreat: evento anual dedicado ao desenvolvimento colaborativo de software para aprimorar habilidades técnicas em comunidade.
• Mentoria: ensinar desenvolvedores com menos experiência em TDD expõe você a novos desafios e contextos de aplicação.
• Diário de aprendizagem: registrar desafios, soluções e lições aprendidas a cada kata ou projeto sustenta a evolução contínua.

Quais são os antipadrões mais comuns ao aplicar TDD?

A Codurance mantém uma série dedicada aos 22 antipadrões de TDD catalogados por James Carr, organizada por Matheus Marabesi em 6 capítulos cada um reunindo testes que geram bases de código inchadas e ciclos de feedback lentos.

Alguns dos antipadrões mais comuns, por capítulo da série:

• Liar (mentiroso): um teste que passa mesmo quando o comportamento que deveria validar está quebrado comum em código assíncrono mal testado.
• Giant (gigante): um único teste enorme cobrindo várias funcionalidades ao mesmo tempo, difícil de ler e de depurar quando falha.
• Excessive Setup (configuração excessiva): testes que exigem tanta preparação que o comportamento real testado fica escondido em meio ao ruído.
• Slow Poke (lento): testes que demoram tanto que o time para de rodá-los a cada mudança e o TDD deixa de existir na prática.
• Mockery (zombaria): uso excessivo de mocks, deixando o teste acoplado à implementação em vez de ao comportamento.
• Free Ride (carona grátis): adicionar novas asserções a um teste existente em vez de escrever um novo teste, dificultando isolar o que quebrou.

Quais boas práticas mantêm os testes de TDD sustentáveis?

Os princípios F.I.R.S.T. resumem o que separa uma suíte de testes saudável de uma que o time evita rodar:

Esses cinco princípios são, na prática, o que o pilar Development Process Quality do SQA audita: presença e disciplina de testes ao longo do tempo, não só se eles existem

Outras práticas que sustentam TDD no dia a dia:

• Nomeie testes pelo comportamento, não pelo método técnico chamado isso torna a suíte legível como documentação.
• Trate código de teste como código de produção: refatore, elimine duplicação e revise com o mesmo rigor.
• Aumente a cobertura enquanto refatora, usando ferramentas como JaCoCo (Java), Istanbul (JavaScript) ou Coverage.py (Python) para acompanhar o progresso.
  

TDD realmente reduz a produtividade do time?

Não de forma significativa e a evidência mais citada sobre o tema aponta o contrário: TDD reduz a densidade de defeitos sem reduzir a produtividade de forma relevante.

Um estudo publicado no periódico Empirical Software Engineering, conduzido por pesquisadores da Microsoft Research e da IBM, comparou equipes que usavam TDD com equipes que não usavam, no mesmo produto e sob a mesma liderança.

O resultado: as equipes com TDD tiveram densidade de defeitos significativamente menor, sem queda relevante de produtividade.

Quais ferramentas usar para aplicar TDD, por linguagem?

A ferramenta importa menos do que a disciplina do ciclo qualquer um desses frameworks sustenta TDD desde que o time escreva o teste antes do código de produção.