Squad Front

Appearance

TDD (Test Driven Development) ​

Desenvolvimento Orientado por Testes (TDD) é uma metodologia onde escrevemos o teste antes mesmo de escrever o código da funcionalidade. O foco é garantir que o comportamento desejado seja atendido desde o primeiro minuto.

1. O Ciclo "Red, Green, Refactor" ​

🔴 Passo 1: Red (Falhar) ​

Escreva um teste que descreve o que a função deve fazer. Como a função ainda não existe ou está vazia, o teste deve falhar.

🟢 Passo 2: Green (Passar) ​

Escreva o código mínimo necessário para fazer o teste passar. Não se preocupe com elegância agora, apenas em resolver o problema.

🔵 Passo 3: Refactor (Melhorar) ​

Com o teste passando (garantia de funcionamento), limpe o código. Aplique SOLID, DRY e KISS. O teste garantirá que você não quebrou nada durante a limpeza.

2. Exemplo Prático: Formatação de Telefone ​

Imagine que precisamos de uma função que formate um número puro 11999998888 para (11) 99999-8888.

❌ 1. Red (O Teste) ​

typescript
// formatPhone.test.ts
import { formatPhone } from './formatPhone';

test('deve formatar o telefone corretamente', () => {
  expect(formatPhone('11999998888')).toBe('(11) 99999-8888');
});

Ao rodar, o teste falha porque formatPhone ainda não existe.

✅ 2. Green (O Código Mínimo) ​

typescript
export function formatPhone(value: string) {
  // Código rápido para o teste passar
  return `(${value.slice(0, 2)}) ${value.slice(2, 7)}-${value.slice(7)}`;
}

Agora o teste passa!

🔵 3. Refactor (A Melhoria) ​

Agora adicionamos validações (ex: e se o valor for vazio?) e melhoramos a legibilidade, sempre rodando o teste após cada mudança.

3. Por que usar TDD no Front-end? ​

  1. Interface Primeiro: Você é forçado a pensar em como a função será chamada (os argumentos) antes de pensar em como ela resolve o problema.
  2. Documentação Viva: O arquivo .test.ts é o melhor exemplo de uso para outro desenvolvedor.
  3. Segurança em Refatorações: No futuro, se trocarmos a biblioteca de formatação, os testes garantirão que o usuário final não perceba diferença.

4. Onde aplicar no projeto? ​

  • Utilitários: Qualquer função na pasta utils.
  • Business Rules: Lógicas de permissão ou cálculos de saúde.
  • Reducers/Selectors: Lógica de manipulação de estado no Redux Toolkit.

5. Quando NÃO usar TDD? ​

  • UI/Estilização: TDD não é eficiente para decidir se um botão deve ser azul ou vermelho.
  • Prototipagem rápida: Quando você ainda não sabe qual será a solução técnica final.
  • Componentes puros do Design System: Onde o foco é a fidelidade visual e não a lógica lógica complexa.