Tdd Engineer

TDD Engineer — Red-Green-Refactor Enforced

Skill que forca o ciclo TDD correto: 1 teste → 1 implementacao → repete. Combate o anti-padrao "escrevo 5 testes, depois 5 implementacoes" — que produz testes ruins (testam shape, nao behavior).

Adaptado de mattpocock/skills/engineering/tdd e integrado ao kit (skill 05 QA + policies/vertical-slices.md).

Governanca Global

Esta skill segue GLOBAL.md, policies/execution.md, policies/quality-gates.md, policies/vertical-slices.md, policies/source-driven.md, policies/writing-clarity.md e policies/verification-before-completion.md (cada passo red→green→refactor exige output verificável da mudança de estado).

Filosofia

Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

Bom teste e integration-style: exercita codigo real atraves de API publica. Descreve o que o sistema faz, nao como. Le como spec — "user can checkout with valid cart" diz exatamente que capacidade existe. Sobrevive a refactor.

Pattern: Approved Fixtures (v2.5.0+)

Inspirado em Birgitta Böckeler (Thoughtworks) — "behaviour harness" é o gap mais difícil da indústria. Approved fixtures é uma das poucas técnicas que aumentam confiança em testes AI-gerados o suficiente pra reduzir supervisão. Ver docs/inspiration/harness-engineering.md.

Conceito

Em vez de o LLM escrever asserções, ele:

1. Roda a feature com inputs de teste
2. Captura o output produzido
3. Você revisa o output uma vez e aprova (commit do "fixture")
4. Testes futuros comparam contra o fixture aprovado

Vantagem: humano revisa dados (concretos, fáceis), não asserções (abstratas, fáceis de errar). Diferente de snapshot testing comum porque o fixture é explicitamente aprovado, não auto-gerado e auto-comparado.

Quando usar

Encaixa bem:

• Output complexo (relatório financeiro, recomendação ML, formatação)
• Transformações de dados (parser → AST, pipeline ETL)
• Renderização (markdown → HTML, JSON → CSV)
• Email/notification rendering

Não encaixa:

• Comportamento dependente de tempo, random, ambiente externo
• Side effects (writes, network calls) — use mock/stub
• Lógica trivial (overhead > ganho)

Workflow

Round 1 — geração inicial
1. Descreve behavior: "função gera relatório mensal"
2. LLM cria teste estrutural:
   - setup input
   - chama função
   - persiste output em fixtures/<feature>.approved.txt
   - assert: output === readFile(fixture)
3. LLM roda → falha (fixture não existe)
4. LLM cria fixture com output atual
5. PARA — passa pro humano

Round 2 — review humano
6. Abrir fixtures/<feature>.approved.txt
7. Verificar se output é semanticamente correto
8. Aprovar (commit) ou rejeitar (descrita erro)

Round 3 — em diante
9. Mudanças que alteram output: fixture quebra
10. LLM mostra diff: "fixture mudou de X pra Y"
11. Aprovar diff (commit) ou tratar como regressão

Anti-padrões

• ❌ Auto-aprovar snapshots sem review (vira sticker)
• ❌ Usar pra lógica trivial (overhead > ganho)
• ❌ Fixtures gigantes (>1KB) — quebra review
• ❌ Fixtures binários — usar perceptual hash
• ❌ Múltiplos asserts no mesmo teste

Integração

• Skill 05 (QA) sugere approved fixtures pra features candidatas
• Subagent test-engineer usa pattern por padrão pra business logic
• /spec flagga: "output complexo → considere approved fixtures"

Tools

• JS/TS: approvals-js
• Python: approvaltests
• Java: approvaltests-java

Referência

• Approval Tests — site canônico
• Llewellyn Falco — autor original do approach

Mau teste acopla a implementacao: mocka colaboradores internos, testa metodo privado, verifica via DB direto. Sinal de alerta: teste quebra ao refactorar sem mudar comportamento. Se renomear funcao interna quebra teste, o teste estava testando implementacao.

Quando Usar

• nova feature com complexidade nao trivial
• bug fix em codigo critico (TDD garante regressao)
• refactor de modulo nao testado (escrever testes pegando o comportamento atual antes de mexer)
• design de modulo novo onde interface ainda nao esta clara (TDD revela interface boa)
• equipe nova precisando convencao de testabilidade

Quando NAO Usar

• script throwaway (data migration uma vez, scaffolding)
• spike exploratorio (descobrir se algo e possivel)
• bug trivial em area amplamente coberta (basta adicionar teste de regressao)
• UI puramente visual (snapshot test pode bastar)

Entradas Esperadas

• spec ou criterio de aceitacao da feature (skill 01 PO ou issue do tracker)
• modulo alvo (path) ou descricao do comportamento
• (opcional) lista de comportamentos prioritarios fornecida pelo usuario
• (opcional) plano de deepening da skill 38 (Architecture Deepener)
• glossario de dominio do projeto (CONTEXT.md ou docs/glossary.md)
• ADRs relevantes (docs/adr/)

Saidas Esperadas

• todos os comportamentos priorizados em verde
• N novos arquivos de teste em tests/ ou __tests__/ (path conforme convencao do projeto)
• relatorio curto: comportamentos cobertos, comportamentos NAO cobertos (escalados para skill 05 QA)
• nenhum teste mocka colaborador interno
• nenhum teste verifica metodo privado
• testes leem como spec ("user can X when Y")
• (se houver refactor pos-GREEN) lista de modulos deepened para skill 38 validar

Anti-Padrao: Horizontal Slicing

NAO escrever todos os testes primeiro, depois toda a implementacao. Isso e horizontal slicing — tratar RED como "escrever todos os testes" e GREEN como "escrever todo o codigo".

Produz testes ruins:

• testes em massa testam comportamento imaginado, nao real
• voce acaba testando shape (estrutura de dados, assinatura) em vez de comportamento user-facing
• testes ficam insensiveis a mudancas reais — passam quando comportamento quebra, falham quando comportamento esta ok
• voce ultrapassa seus farois — commit a estrutura de teste antes de entender a implementacao

ERRADO (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

CERTO (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3
  ...

Esta diretriz ecoa policies/vertical-slices.md — fatia vertical, nao horizontal.

Workflow

Fase 1 — Planning

Ao explorar codebase, usar glossario de dominio do projeto para que nomes de teste e vocabulario de interface batam com a linguagem do projeto. Respeitar ADRs na area tocada.

Antes de escrever qualquer codigo:

• Confirmar com usuario quais mudancas de interface sao necessarias
• Confirmar com usuario quais comportamentos testar (priorizar)
• Identificar oportunidades de deep modules (interface pequena, implementacao profunda — ver skill 38)
• Desenhar interfaces para testabilidade
• Listar comportamentos a testar (NAO passos de implementacao)
• Obter aprovacao do usuario no plano

Pergunta-chave: "Como deve ser a interface publica? Quais comportamentos sao mais importantes testar?"

Voce nao pode testar tudo. Confirmar com usuario quais comportamentos importam mais. Foco em paths criticos e logica complexa, nao todo edge case possivel.

Fase 2 — Tracer Bullet

Escrever UM teste que confirma UMA coisa sobre o sistema:

RED:   Escrever teste para o primeiro comportamento → teste falha
GREEN: Escrever codigo minimo para passar → teste passa

Esse e o tracer bullet — prova que o caminho funciona end-to-end.

Fase 3 — Loop Incremental

Para cada comportamento restante:

RED:   Escrever proximo teste → falha
GREEN: Codigo minimo para passar → passa

Regras:

• um teste por vez
• so codigo suficiente para passar o teste atual
• nao antecipe testes futuros
• mantenha testes focados em comportamento observavel

Fase 4 — Refactor

Apos todos os testes passarem, procurar oportunidades de refactor:

• Extrair duplicacao
• Aprofundar modulos (mover complexidade atras de interface simples — coordenar com skill 38)
• Aplicar SOLID onde natural
• Considerar o que o codigo novo revela sobre codigo existente
• Rodar testes apos cada passo de refactor

Nunca refactore enquanto RED. Chegue ao GREEN primeiro.

Se um refactor quebrar um teste que passava: o refactor mudou comportamento observável, não só estrutura interna — reverter o passo de refactor (não ajustar o teste pra passar de novo). Um teste bem escrito sobrevive a refactor por definição (checklist abaixo); teste quebrado por refactor é sinal de que o refactor extrapolou escopo ou o teste testava implementação, não comportamento.

Checklist Por Ciclo

[ ] Teste descreve comportamento, nao implementacao
[ ] Teste usa apenas interface publica
[ ] Teste sobreviveria a refactor interno
[ ] Codigo e minimo para esse teste
[ ] Nenhuma feature especulativa adicionada

Anti-Rationalization Table

Pensamentos que indicam STOP — voce esta racionalizando:

Heuristicas de Boa Interface (para testabilidade)

• Deep module: interface pequena, comportamento rico. Test count baixo + cobertura alta.
• Argumentos primitivos > objetos complexos: facilita setup de teste sem mocks elaborados.
• Funcao pura > stateful: input → output testavel sem fixture.
• Side effect declarado > escondido: facilita asserir que aconteceu.
• Erro e retorno > excecao: simplifica matrix de teste (sem try/catch).

Coordenar com skill 38 (Architecture Deepener) para identificar modulos shallow que merecem deepening antes de escrever teste.

Integracao com Vertical Slices

TDD opera dentro de uma vertical slice. Sequencia:

1. /to-issues quebra feature em vertical slices
2. Cada worker pega 1 slice
3. Dentro do slice: TDD red-green-refactor por comportamento
4. Slice completa quando todos os comportamentos prioritarios estao verdes

NAO tentar TDD cross-slice — comportamento de slice X nao deve depender de teste de slice Y.

Evidencia de Conclusao

• todos os comportamentos priorizados verdes
• nenhum teste foi escrito antes de ver o respectivo RED
• refactor passada apos GREEN final, todos os testes ainda verdes
• nenhum teste mocka colaborador interno
• nenhum teste verifica metodo privado
• testes leem como spec ("user can X when Y")

Handoff

Apos conclusao:

• caminho dos testes adicionados
• contagem (N novos testes, M cobertura aumentada)
• modulos que ganharam deepening (se aplicavel) → skill 38 valida
• proxima: skill 11 (Reviewer) valida que testes nao mockam implementacao

Integracao com Pipeline

• PO (skill 01): criterios de aceitacao alimentam lista de comportamentos prioritarios
• Backend (03) + Frontend (04): implementacao do GREEN
• QA Engineer (05): complementa com edge cases nao priorizados em TDD
• Reviewer (11): valida disciplina TDD (sem mock interno, sem teste de privado)
• Architecture Deepener (38): coordena para identificar deep modules antes do RED
• /build: pode ativar TDD se task descrita como "TDD" ou "test-first"

XP — TDD no contexto da metodologia completa

TDD não é uma técnica isolada: é o núcleo técnico do eXtreme Programming, e o livro eXtreme Programming — práticas para o dia a dia (Casa do Código) é enfático em que as práticas só funcionam em sinergia — "muitas vezes uma prática só funciona porque depende das outras". Esta skill cobre o red-green-refactor; o resto do XP é processo compartilhado e vive nas policies:

• Pareamento e posse coletiva → policies/pair-programming.md. Revezar piloto/copiloto por ciclo de TDD (um escreve o RED, o outro faz o GREEN e refatora) é a forma canônica de parear no kit.
• Integração contínua / trunk-based → policies/continuous-integration.md. O GREEN só "conta" quando o build verde integra no trunk — "não quebre o build" é o análogo XP do verification-before-completion.
• Ritmo sustentável → policies/sustainable-pace.md. Não pular testes para "agilizar": defeito vira retrabalho que quebra o ritmo das próximas iterações.
• Simplicidade / YAGNI → não há policy dedicada (seria redundante). Vive na tríade policies/vertical-slices.md + policies/boil-the-lake.md + Senior Dev Override do GLOBAL.md. O "código mínimo para passar o teste atual" da Fase 3 desta skill é YAGNI aplicado ao ciclo.

Se for adotar XP num projeto, o livro recomenda começar pelo teste automatizado ("se tiver que escolher uma prática para começar, escolha o teste automatizado") — ou seja, por esta skill — e ir incorporando as policies acima.

Material Adicional

Para deep dives consultar:

• docs/skill-guides/tdd-deep-modules.md (a criar conforme demanda) — adaptacao de tdd/deep-modules.md
• docs/skill-guides/tdd-interface-design.md — interface design para testabilidade
• docs/skill-guides/tdd-mocking.md — quando mockar (raramente) e como
• docs/skill-guides/tdd-refactoring.md — refactor checklist apos GREEN