Executar TDD orientado pelo BDD da especificação
Modo de interação
Modo de interação:
.
Antes de formular qualquer pergunta, leia e aplique o
Contrato de perguntas numeradas
de
.
Leia o BDD como referência e converta o comportamento especificado em testes TDD
executáveis e evidência rastreável. O Gherkin ajuda o usuário e o agente a
entender contexto, ação e resultado; ele próprio não é uma suíte de testes.
Orquestrar a conversa
Ao concluir esta etapa ou detectar trabalho de outra etapa, anuncie
Pendência detectada: <descrição> — ação: resolvendo nesta etapa
e resolva-a
quando pertencer ao próprio escopo. Quando houver troca de responsabilidade,
anuncie
Transição automática: $specsfy-06-tdd-bdd → $<destino> — motivo: <motivo> — resultado esperado: <resultado>
e carregue imediatamente a skill de
destino, sem pedir confirmação nem repetir o comando. Continue na mesma
conversa. Depois de uma correção necessária a esta etapa, anuncie
Retomada automática: $<destino> → $specsfy-06-tdd-bdd — pendência resolvida: <resultado>
e retome-a imediatamente. Reavalie o estado após cada handoff para
evitar ciclos. Não peça confirmação para o handoff; ações sensíveis continuam
exigindo autorização específica.
Escolher o modo
- : antes da implementação, criar o próximo teste/scenario e provar RED sem escrever código de produção.
- : executar RED → GREEN → REFACTOR para uma fatia explicitamente escolhida.
- : executar suites e auditar rastreabilidade sem criar comportamento novo.
Se o usuário não indicar o modo, use
quando a seção 14 ainda não estiver em execução e
quando houver uma tarefa ativa.
Preparar
- Leia
specs/<estado>/<NNNN>-<slug>/spec.md
- Exija e . No modo ,
use e ; nos modos e ,
use ou .
- Selecione uma fatia vertical pequena: um Gherkin e seus .
- Resolva o runner de testes pela stack antes de escrever testes:
- projeto PHP ( ou ), inclusive PHP + Node: use Pest;
- projeto Node sem PHP: pergunte ao usuário qual runner adotar antes de
instalar ou configurar; recomende Vitest por padrão;
- outra stack: preserve o runner de testes existente ou pergunte quando não houver
decisão reproduzível.
- Em Node, considere a decisão materializada quando expuser o
script ; não escolha nem instale dependência silenciosamente.
- Leia
references/test-levels.md
Usar o BDD para escrever TDD
- Use o bloco Gherkin do em como contrato de referência sem mudar
seu significado.
- Não crie, copie nem execute arquivos ou step definitions. Os termos
Given/When/Then permanecem apenas na .
- Em PHP, escreva o teste TDD com Pest em ou , no
menor nível que prova o comportamento. Marque cada caso executável,
imediatamente junto à sua definição, com:
php
// SPECSFY: US-001 FR-001 AC-001
- Em Node, depois da resposta do usuário, escreva o teste TDD no runner
escolhido e use
SPECSFY: US-001 FR-001 AC-001
- Materialize no mínimo três casos TDD distintos para a feature inteira e para
cada , e : caminho feliz, regra/variação crítica e falha ou
limite material. Um único marcador compartilhado pelo arquivo
conta como um caso, mesmo que o arquivo contenha vários testes.
- Cubra cada com ao menos um caso TDD, sem multiplicar casos equivalentes.
- Escolha unidade, integração, contrato ou browser conforme a fronteira descrita
pelo BDD; não crie uma segunda suíte apenas para rotulá-la como BDD.
- Não use mocks para remover justamente a fronteira que o cenário pretende provar.
Ciclo obrigatório
RED
- Leia o BDD de referência e escreva o menor teste TDD que prova o e seus
requisitos.
- Execute o teste TDD; nunca execute Gherkin.
- Confirme falha pelo comportamento ausente ou incorreto.
- Se falhar por sintaxe, fixture, importação ou ambiente, corrija o teste e repita.
- Se passar antes da mudança, o teste não demonstra o gap: refine-o ou prove que a funcionalidade já existe.
No modo
, pare após o RED válido, registre evidência e conclua o
checklist da tarefa
correspondente. Não
altere
; anuncie e retorne automaticamente para
, que valida todos os predecessores antes de promover a
spec para
.
Registre a linha correspondente na tabela
Evidência RED-GREEN-REFACTOR
com o RED observado.
GREEN
No modo
, escreva o mínimo de código de produção que satisfaça o cenário. Execute primeiro o teste focal e depois a suite relacionada. Não generalize antes de haver um exemplo que exija generalização.
Atualize a mesma linha de evidência com o GREEN observado.
REFACTOR
Com tudo verde, elimine duplicação e melhore nomes/estrutura sem alterar comportamento. Execute novamente as suites relacionadas.
Registre o comando de regressão na seção 11 e a evidência na matriz da seção 12.
Auditar rastreabilidade
Execute:
bash
node .agents/skills/specsfy-06-tdd-bdd/scripts/check_traceability.mjs specs/<estado>/<NNNN>-<slug>/spec.md .
Trate como gap cada feature,
,
ou
com menos de três casos TDD e
cada
sem ao menos um caso. Para
verificado manualmente ou por
observabilidade, cite a evidência sem dispensar os três casos automatizáveis;
quando necessário, ajuste
sem remover IDs aplicáveis.
Em specs com
, acrescente
para exigir
US/FR/NFR/AC → teste → tarefa → evidência
.
Durante execução, mantenha
Delivery Gate: In Progress
e atualize o
Gate do Ato III — Entrega
da seção 13. Use
somente quando não houver
gap obrigatório, todas as tarefas estiverem concluídas e a Definition of Done
estiver comprovada.
Disciplina sob pressão
| Tentação | Regra |
|---|
| “É uma mudança pequena.” | Mudanças pequenas recebem testes pequenos; tamanho não substitui RED. |
| “O código já está pronto.” | Escreva um teste de caracterização; não altere produção para fabricar RED. Para comportamento novo, escolha um caso ainda não atendido. |
| “O prazo permite pular RED.” | Sem falha observada não há prova de que o teste protege o requisito. |
| “O líder autorizou.” | Autoridade pode mudar escopo, não transformar ausência de evidência em TDD. |
| “Testar depois é equivalente.” | Test-first guia o contrato e prova sensibilidade antes da implementação. |
Em uma tarefa de teste, atualize
,
,
,
e
conforme cada etapa acontecer. Não marque o pai como concluído sem arquivo, marcador, RED válido, comando/evidência e revisão do processo.
Não escreva código de produção antes que o predecessor TDD informado pelo BDD
da mesma fatia esteja concluído e com RED registrado na spec.
Auditar QA
Depois de executar os runners pertencentes ao repositório, registre
ou
a falha na coluna Evidência da seção 12 e audite:
bash
node .agents/skills/specsfy-06-tdd-bdd/scripts/verify_acceptance.mjs \
specs/<estado>/<NNNN>-<slug>/spec.md .
O auditor não executa comandos extraídos de Markdown. AC manual exige método,
responsável e evidência; AC sem resultado impede
.
Quando houver atestação do runner, repita com
: o auditor
exige exatamente o check
aprovado, detail JSON válido e
cobertura de todos os ACs. Texto
isolado não substitui essa prova.
Relatar evidência
Informe a fatia, IDs cobertos, arquivo do teste, comando RED, causa da falha, comando GREEN quando aplicável, suite de regressão e gaps de rastreabilidade.
Especialistas sob demanda
Leia references/specialists.md quando o runner,
boundary ou oráculo de teste for específico de uma tecnologia. O especialista
complementa; esta skill preserva RED/GREEN e rastreabilidade.