1. Panorama: por que debugging é parte central do TDD

Na prática de TDD, o ciclo Red-Green-Refactor exige que as falhas sejam encontradas e compreendidas rapidamente, sem quebrar o fluxo de testes. A abordagem de debugging precisa ser disciplinada, previsível e embasada em evidências obtidas pelos próprios testes. Abaixo, compartilho técnicas que usei em projetos de alta maturidade, onde a qualidade do código depende de diagnósticos precisos.

• Defina metas de diagnóstico: o que você precisa entender para prosseguir sem adivinhar o comportamento esperado.
• Priorize reproduzibilidade: se a falha não puder ser reproduzida, não avance. Recrie o cenário com precisão mínima.
• Acompanhe o feedback: cada teste deve te dar um confinamento claro do que está errado.

O isolamento é crucial para evitar que falhas externas poluam o diagnóstico. Em TDD, você deve conseguir falhar apenas pela unidade sob teste. Aplique as seguintes técnicas:

• Injeção de dependências (DI): passe as dependências como argumentos ou por construtor. Facilita a troca por doubles durante os testes.
• Mocks, stubs e fakes: crie objetos simulados que representam o comportamento esperado das dependências. Use-os para forçar cenários de borda e erros.
• Contratos de API: mantenha contratos estáveis entre componentes. Quando falhar, saberás se a culpa é do contrato ou da implementação.
• Observabilidade de chamadas: registre chamadas para dependências mocked para entender o que foi solicitado durante o teste.

Exemplo simples em TypeScript com DI e mocks:

// Arquitetura simples com DI
type User = { id: number; name: string; };
interface Api {
  getUser(id: number): Promise<User>;
}
class GreetingService {
  constructor(private api: Api) {}
  async greet(id: number): Promise<string> {
    const u = await this.api.getUser(id);
    return `Olá, ${u.name}`;
  }
}

// Testes com doubles
describe('GreetingService', () => {
  it('retorna saudação quando user é fetchado', async () => {
    const mockApi: Api = { getUser: jest.fn().mockResolvedValue({ id: 1, name: 'Ana' }) };
    const svc = new GreetingService(mockApi);
    const res = await svc.greet(1);
    expect(res).toBe('Olá, Ana');
  });

  it('propaga erro de API', async () => {
    const mockApi: Api = { getUser: jest.fn().mockRejectedValue(new Error('not found')) };
    const svc = new GreetingService(mockApi);
    await expect(svc.greet(1)).rejects.toThrow('not found');
  });
});

O padrão acima permite isolar a lógica de apresentação da forma como os dados são obtidos. Quando o teste falha, você sabe se o problema está na lógica de negócios ou no contrato da API simulada.

3. Estratégias de reprodução de falhas: logs, observabilidade e ambiente de testes

Reprodução confiável é a base para diagnóstico eficiente. Adote abordagens que gerem evidências claras do que ocorreu:

• Logs estruturados: inclua contexto (IDs de request, estados do fluxo, métricas). Evite logs genéricos que não ajudam a entender o caminho da falha.
• Snapshot de estado: capture o estado relevante da aplicação no momento da falha para comparação de regressões.
• Verificações adicionais nos tests: adicione asserts que cobrem espaços de falha raros (edge cases) para evitar regressões silenciosas.
• Ambiente de teste previsível: use a mesma configuração de ambiente entre reproduções, com dependências controladas e dados de teste consistentes.

4. Técnicas avançadas de debugging durante o TDD

Neste ponto, reúno técnicas operacionais que aumentam a produtividade sem perder o foco no ciclo rápido de feedback:

• Teste por escopo menor: reduza o escopo da unidade até que o erro fique evidente, retornando ao escopo anterior apenas quando necessário.
• Estruture testes com ganho de diagnóstico: escreva testes que não apenas afirmem o que funciona, mas também capturem o que não funciona e por quê.
• Utilize “test doubles” com foco em comportamento: verifique não apenas o valor retornado, mas também as interações entre componentes (chamadas, Order of calls).
• Estratégias de breakpoint suaves: insira breakpoints em pontos específicos do código para inspecionar estados apenas quando a falha está próxima do alvo.
• Cobertura orientada a falhas: não apenas medir cobertura, mas examinar quais caminhos de erro foram exercitados pelo seu conjunto de testes.

A prática recomendada é manter o fluxo de TDD intacto: escreva um teste falho, implemente o mínimo para fazê-lo passar, e refatore com segurança. Use as técnicas acima para guiar o diagnóstico sem descer o nível de confiança do seu pipeline de CI.

Exemplo de debugging com doubles (quando a falha envolve dependências)

Este snippet demonstra como introduzir mocks para isolar a unidade e entender a origem de uma falha sem depender de serviços externos.

// Exemplo adicional: validação de contrato com doubles
interface PaymentGateway {
  charge(amount: number, currency: string): Promise<string>; // returns transaction id
}
class Checkout {
  constructor(private gateway: PaymentGateway) {}
  async purchase(amount: number, currency: string) {
    if (amount <= 0) throw new Error('amount_invalid');
    const txId = await this.gateway.charge(amount, currency);
    return txId;
  }
}

describe('Checkout', () => {
  it('faz a cobrança com a gateway', async () => {
    const gateway: PaymentGateway = { charge: jest.fn().mockResolvedValue('tx-123') };
    const co = new Checkout(gateway);
    const tx = await co.purchase(100, 'USD');
    expect(tx).toBe('tx-123');
  });

  it('falha quando amount é inválido', async () => {
    const gateway: PaymentGateway = { charge: jest.fn() };
    const co = new Checkout(gateway);
    await expect(co.purchase(-5, 'USD')).rejects.toThrow('amount_invalid');
  });
});