TDD em Java do zero: como os testes mudam o código e salvam os nervos

Por que TDD não é sobre "escrever testes", mas sobre "pensar de forma diferente"

Imagine que você está construindo uma casa. Você tem plantas, materiais e uma equipe. Mas você começa a colocar tijolos sem verificar a fundação. Um mês depois, descobre que as paredes estão rachadas. Familiar? Na programação, isso é chamado de "depois a gente conserta". E "depois" geralmente acontece às 3 da manhã antes do deploy.

Desenvolvimento Orientado a Testes (TDD — Test-Driven Development) é uma técnica que vira o processo de cabeça para baixo. Você não escreve o código e depois os testes. Você primeiro escreve o teste — e só depois o código que passa nesse teste. Parece loucura? Na prática, isso economiza horas, nervos e deixa o código mais limpo que o ar da manhã nas montanhas.

Neste artigo, vamos analisar o TDD em Java com exemplos concretos. Nada de enrolação — apenas código, o ciclo Red-Green-Refactor e cenários reais. Vamos nessa.

O que é TDD e como funciona o ciclo Red-Green-Refactor

O TDD é baseado em três etapas simples, que se repetem ciclicamente:

\n
• Red — escrevemos um teste que não passa (ele deve falhar).
\n
• Green — escrevemos o código mínimo para o teste passar.
\n
• Refactor — melhoramos o código sem alterar seu comportamento. Os testes permanecem verdes.
\n

Parece que isso desacelera o desenvolvimento. Na verdade, acelera. Você para de adivinhar "será que isso funciona?". Você sabe: funciona, porque o teste está verde.

Princípios principais do TDD

\n
• Não escreva uma única linha de código de produção sem um teste.
\n
• O teste deve ser o mais simples possível e verificar exatamente um comportamento.
\n
• O código é escrito apenas o suficiente para o teste passar. Nada de "vamos colocar isso também só por precaução".
\n

Agora vamos para Java e JUnit 5 — o framework mais popular para testes unitários.

Configuração do projeto: Maven, JUnit 5 e estrutura

Para os exemplos, usaremos Maven. Adicione a dependência no pom.xml:

<dependency>\n    <groupId>org.junit.jupiter</groupId>\n    <artifactId>junit-jupiter-api</artifactId>\n    <version>5.10.0</version>\n    <scope>test</scope>\n</dependency>

A estrutura de pastas é padrão para Maven:

src/\n  main/java/com/exemplo/\n  test/java/com/exemplo/

Todas as classes de teste são colocadas em src/test/java. O nome da classe de teste geralmente corresponde ao nome da classe testada + o sufixo Test. Por exemplo, Calculator → CalculatorTest.

Primeiro ciclo TDD: criando uma calculadora do zero

Tarefa: criar o método add(int a, int b), que retorna a soma. Pelo TDD, começamos não pela classe, mas pelo teste.

Passo 1: Red — escrevemos um teste que vai falhar

import org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.*;\n\npublic class CalculatorTest {\n\n    @Test\n    void shouldAddTwoNumbers() {\n        Calculator calc = new Calculator();\n        int result = calc.add(2, 3);\n        assertEquals(5, result);\n    }\n}

Tentamos executar — o compilador reclama: a classe Calculator não existe. Ótimo, a luz vermelha está acesa.

Passo 2: Green — escrevemos o código mínimo

Criamos a classe Calculator com um método que simplesmente retorna a soma:

public class Calculator {\n    public int add(int a, int b) {\n        return a + b;\n    }\n}

Executamos o teste — verde. A implementação mínima possível funcionou.

Passo 3: Refactor

Nesta etapa, o código já é simples, não há nada para refatorar. Mas imagine que queremos renomear o método ou adicionar uma verificação de estouro. Fazemos isso, e o teste ainda passa. Se algo quebrar — o teste falhará e apontará imediatamente o problema.

Compl