---
id: create-suite
agent: qa
title: Criar a suíte de testes da story
inputs: [story]
outputs: [arquivos de teste, mapa AC→teste em Given-When-Then, File List da suíte]
elicit: false
modes: [interactive, yolo]
---

# Criar a suíte de testes da story

**Objetivo:** transformar os critérios de aceite de uma story em uma suíte de testes executável e
rastreável — cada AC com pelo menos um teste em Given-When-Then — sem inventar requisito e sem tocar o
código de produção.

**Pré-condições:**
- A story existe e tem ACs explícitos e a seção de Testing. Se faltar AC ou Testing, **pare** e
  devolva ao @sm/@po — eu não invento o contrato que vou testar (No invention, Art. IV).
- A story NÃO está em `Draft` (foi validada). Desenhar suíte sobre contrato não-validado é retrabalho.
- Conheço o framework de testes do projeto (runner, convenção de pasta, comando de execução). Se não
  estiver definido na story/arquitetura, **pare** e elicito — não escolho stack por conta própria.

## Passos

1. **Leio a story completa** — ACs, Dev Notes, seção de Testing. Defino o que "pronto" significa AQUI
   antes de escrever qualquer teste.
2. **Perfilo o risco por AC** (probabilidade × impacto). Caminho crítico e dado sensível recebem
   cobertura profunda (caso de erro, borda, regressão); CRUD trivial recebe cobertura proporcional.
   Profundidade segue o sinal de risco, não o meu humor.
3. **Mapeio cada AC para cenário(s)** em Given-When-Then. AC sem cenário é um buraco — eu o nomeio,
   não o ignoro. O mapa AC→teste é artefato de saída obrigatório.
4. **Escrevo os testes**, seguindo a convenção do projeto (REUSE > ADAPT > CREATE: reutilizo helpers/
   fixtures existentes antes de criar). Para cada AC:
   a. caminho feliz que prova o AC;
   b. ao menos um caso de erro/borda quando o risco aponta;
   c. teste de regressão quando o AC nasce de um bug conhecido.
5. **Rodo a suíte** no runner do projeto. Testes novos podem ficar vermelhos se o código ainda não
   existe — registro claramente quais falham por código ausente (esperado) versus por defeito real.
6. **Registro a File List da suíte** (arquivos de teste criados/modificados) e entrego o mapa AC→teste
   junto. Esse é o rastro que o gate vai auditar.
7. **Roteio.** Suíte pronta → @dev implementa contra ela (TDD) ou eu sigo para `*review`/`*gate` se o
   código já existe. Eu **nunca** escrevo o código de produção que faz a suíte passar — isso é do @dev.

## Critério de pronto (DoD)

- [ ] Todo AC mapeado para pelo menos um teste em Given-When-Then (zero AC órfão)
- [ ] Casos de erro/borda presentes onde o perfil de risco aponta
- [ ] Suíte roda no runner do projeto; falhas classificadas (código ausente × defeito real)
- [ ] File List da suíte e mapa AC→teste entregues
- [ ] Reutilizei helpers/fixtures existentes antes de criar novos
- [ ] Não toquei o código de produção nem qualquer seção da story além da minha

## Falha / recuperação

- **AC ambíguo ou não-testável** → paro, registro a lacuna e devolvo ao @sm/@po. Não invento a
  interpretação que falta.
- **Framework de testes indefinido** → paro e elicito; não escolho stack por conta própria.
- **A suíte exige tocar schema/migration além do teste** → delego ao @data-engineer para validar/
  otimizar; eu não invado a lane de dados.
- **Preciso subir a suíte (push/PR)** → delego ao @devops, sempre. Eu não faço `git push` nem abro PR;
  commit local é do @dev.