Praticante7 min de leitura

TDD na prática

Vermelho, verde, refatorar como ferramenta de design, não como cerimônia, com os erros comuns a evitar.

O desenvolvimento orientado por testes (TDD) tem menos a ver com testar e mais com projetar sob pressão. Escrever o teste primeiro obriga você a usar o código antes de ele existir, o que expõe interfaces estranhas enquanto ainda é barato mudá-las.

O ciclo

Vermelho: escreva o menor teste que falha para a próxima fatia de comportamento. Veja-o falhar pelo motivo certo.
Verde: escreva o mínimo de código que o faz passar. Aqui vale fixar o valor no código, de propósito.
Refatorar: com a barra verde como rede de proteção, tire a duplicação e melhore os nomes. Rode os testes de novo.

Nota: A disciplina está na ordem e no tamanho dos passos. Passos pequenos dão retorno rápido, e a barra verde entre eles é o que torna a refatoração segura.

Um microexemplo

// Vermelho: o comportamento que queremos, antes de qualquer implementação
import { describe, it, expect } from 'vitest';
import { fizzbuzz } from './fizzbuzz';

describe('fizzbuzz', () => {
  it('returns the number as a string by default', () => {
    expect(fizzbuzz(1)).toBe('1');
  });

  it('returns "Fizz" for multiples of 3', () => {
    expect(fizzbuzz(3)).toBe('Fizz');
  });
});

// Verde: o mínimo de código que satisfaz os testes atuais
export function fizzbuzz(n: number): string {
  if (n % 3 === 0) return 'Fizz';
  return String(n);
}
// Só refatore quando um terceiro teste (múltiplos de 5, depois de 15) exigir estrutura.

Erros comuns

Escrever a implementação inteira e depois preencher os testes: isso é teste depois do código com crachá de TDD.
Passos grandes demais: um teste que falha e precisa de 50 linhas para passar não dá retorno nenhum sobre o design.
Testar diretamente auxiliares privados, em vez do comportamento público que os motivou.
Pular a etapa de refatorar: o ganho de design está no verde sobre verde.

Faça o ciclo você mesmo no TDD Learning Lab: ele guia você pelo vermelho, verde, refatorar em exercícios reais e roda seus testes em um Web Worker isolado.

Pratique isto

TDD Learning Lab →

Leia a seguir

O ciclo

Vermelho: escreva o menor teste que falha para a próxima fatia de comportamento. Veja-o falhar pelo motivo certo.

Verde: escreva o mínimo de código que o faz passar. Aqui vale fixar o valor no código, de propósito.

Refatorar: com a barra verde como rede de proteção, tire a duplicação e melhore os nomes. Rode os testes de novo.

Nota: A disciplina está na ordem e no tamanho dos passos. Passos pequenos dão retorno rápido, e a barra verde entre eles é o que torna a refatoração segura.

Um microexemplo

// Vermelho: o comportamento que queremos, antes de qualquer implementação import { describe, it, expect } from 'vitest'; import { fizzbuzz } from './fizzbuzz'; describe('fizzbuzz', () => { it('returns the number as a string by default', () => { expect(fizzbuzz(1)).toBe('1'); }); it('returns "Fizz" for multiples of 3', () => { expect(fizzbuzz(3)).toBe('Fizz'); }); });

// Verde: o mínimo de código que satisfaz os testes atuais export function fizzbuzz(n: number): string { if (n % 3 === 0) return 'Fizz'; return String(n); } // Só refatore quando um terceiro teste (múltiplos de 5, depois de 15) exigir estrutura.

Erros comuns

Escrever a implementação inteira e depois preencher os testes: isso é teste depois do código com crachá de TDD.

Passos grandes demais: um teste que falha e precisa de 50 linhas para passar não dá retorno nenhum sobre o design.

Testar diretamente auxiliares privados, em vez do comportamento público que os motivou.

Pular a etapa de refatorar: o ganho de design está no verde sobre verde.

Faça o ciclo você mesmo no TDD Learning Lab: ele guia você pelo vermelho, verde, refatorar em exercícios reais e roda seus testes em um Web Worker isolado.