feat: tipo de cenario -- MANUAL_STEPS/BDD/CHECKLIST/EXPLORATORY (item 5) #50

Merged

jhony75 merged 1 commit from feature/scenario-types into develop 2026-09-09 19:32:43 -03:00

Conversation 0 Commits 1 Files changed 15 +409 -35

jhony75 commented 2026-09-09 19:14:49 -03:00

Owner

Copy link

Implementa o item 5 do roadmap: tipo/estilo de autoria do cenario.

Empilhado sobre #49 (feature/shared-steps, ainda nao mergeada), que por sua vez empilha sobre #48 (feature/scenario-external-key-edit, ainda nao mergeada). Ordem de merge: #48 -> #49 -> esta.

O que muda

TestScenarioTemplate ganha type: MANUAL_STEPS | BDD | CHECKLIST | EXPLORATORY -- vocabulario fechado no mesmo padrao ja usado por outcome/failure_classification (String simples + Literal no Pydantic, sem Enum de banco). AUTOMATED deliberadamente NAO e um tipo -- automacao e capacidade/implementacao de um cenario, nao uma categoria de autoria.

Auditoria antes de implementar confirmou que esse conceito nao existia em NENHUM lugar do codigo -- so um keyword Given/When/Then opcional por passo, sem validacao nenhuma. Pra que o tipo mude comportamento real (regra explicita do roadmap: "nao adicionar tipo que so muda aparencia"), cada tipo agora exige coerencia real com a keyword dos passos:

• BDD exige keyword (Given/When/Then/And/But) obrigatoria em todo passo.
• CHECKLIST proibe keyword em qualquer passo.
• MANUAL_STEPS e EXPLORATORY nao restringem nada -- EXPLORATORY reaproveita 100% a lista de passos e o modelo de Run atual, so tratada como notas de alto nivel na UI (escopo deliberadamente pequeno nesta rodada, sem redesenhar execucao).

A validacao roda depois de resolver eventuais Shared Steps (senao um passo vinculado poderia burlar a regra), e valida os passos que JA existem mesmo quando so o type muda num PUT sem reenviar steps. type conta como CONTEUDO pra fins de versionamento -- redefine o que os passos do cenario significam, entao editar-lo bump a versao e grava historico, igual a name/description/steps.

Decisoes de produto confirmadas com o usuario (AskUserQuestion)

1. BDD exige keyword obrigatoria (nao so opcional/sugerida).
2. CHECKLIST esconde/proibe keyword completamente.
3. EXPLORATORY fica com escopo pequeno nesta rodada (reaproveita Run atual) em vez de redesenhar execucao pra sessao livre.
4. Tipo pode ser trocado livremente depois de criado (nao trava).

Frontend

Seletor de tipo no ScenarioBuilder, com normalizacao imediata ao trocar (BDD preenche keyword em branco com "Given", CHECKLIST limpa keyword de todo passo) pra manter a UI sempre coerente com o que o backend valida -- keyword fica escondida pra CHECKLIST e sem a opcao vazia "—" pra BDD. Checagem espelhada no cliente antes do submit evita um round-trip previsivel; o backend continua sendo a fonte de verdade. Badge de tipo na Library (detalhe e historico), reaproveitando domainStatusVariants.ts do item 3.

Verificacao

• Backend: pytest -n auto -- 172 passed (6 testes novos).
• Frontend: tsc --noEmit, eslint, vitest -- 125 passed (4 testes novos), build, build-storybook -- todos ok.
• Manual, contra o dev real: criar cenario BDD sem keyword em algum passo rejeita com mensagem clara; criar com keyword em todos aceita; trocar tipo BDD -> CHECKLIST limpa a keyword na UI e persiste limpo; historico mostra o tipo de cada versao antiga corretamente (v1 BDD preservado apos virar v2 Checklist).

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

Implementa o item 5 do roadmap: tipo/estilo de autoria do cenario. **Empilhado sobre #49** (`feature/shared-steps`, ainda nao mergeada), que por sua vez empilha sobre **#48** (`feature/scenario-external-key-edit`, ainda nao mergeada). Ordem de merge: #48 -> #49 -> esta. ## O que muda `TestScenarioTemplate` ganha `type`: `MANUAL_STEPS` | `BDD` | `CHECKLIST` | `EXPLORATORY` -- vocabulario fechado no mesmo padrao ja usado por `outcome`/`failure_classification` (String simples + `Literal` no Pydantic, sem Enum de banco). `AUTOMATED` deliberadamente NAO e um tipo -- automacao e capacidade/implementacao de um cenario, nao uma categoria de autoria. Auditoria antes de implementar confirmou que esse conceito nao existia em NENHUM lugar do codigo -- so um `keyword` Given/When/Then opcional por passo, sem validacao nenhuma. Pra que o tipo mude comportamento real (regra explicita do roadmap: "nao adicionar tipo que so muda aparencia"), cada tipo agora exige coerencia real com a keyword dos passos: - **BDD** exige keyword (Given/When/Then/And/But) obrigatoria em todo passo. - **CHECKLIST** proibe keyword em qualquer passo. - **MANUAL_STEPS** e **EXPLORATORY** nao restringem nada -- EXPLORATORY reaproveita 100% a lista de passos e o modelo de Run atual, so tratada como notas de alto nivel na UI (escopo deliberadamente pequeno nesta rodada, sem redesenhar execucao). A validacao roda depois de resolver eventuais Shared Steps (senao um passo vinculado poderia burlar a regra), e valida os passos que JA existem mesmo quando so o `type` muda num PUT sem reenviar `steps`. `type` conta como CONTEUDO pra fins de versionamento -- redefine o que os passos do cenario significam, entao editar-lo bump a versao e grava historico, igual a name/description/steps. ## Decisoes de produto confirmadas com o usuario (AskUserQuestion) 1. BDD exige keyword obrigatoria (nao so opcional/sugerida). 2. CHECKLIST esconde/proibe keyword completamente. 3. EXPLORATORY fica com escopo pequeno nesta rodada (reaproveita Run atual) em vez de redesenhar execucao pra sessao livre. 4. Tipo pode ser trocado livremente depois de criado (nao trava). ## Frontend Seletor de tipo no `ScenarioBuilder`, com normalizacao imediata ao trocar (BDD preenche keyword em branco com "Given", CHECKLIST limpa keyword de todo passo) pra manter a UI sempre coerente com o que o backend valida -- keyword fica escondida pra CHECKLIST e sem a opcao vazia "—" pra BDD. Checagem espelhada no cliente antes do submit evita um round-trip previsivel; o backend continua sendo a fonte de verdade. Badge de tipo na Library (detalhe e historico), reaproveitando `domainStatusVariants.ts` do item 3. ## Verificacao - Backend: `pytest -n auto` -- 172 passed (6 testes novos). - Frontend: `tsc --noEmit`, `eslint`, `vitest` -- 125 passed (4 testes novos), `build`, `build-storybook` -- todos ok. - Manual, contra o dev real: criar cenario BDD sem keyword em algum passo rejeita com mensagem clara; criar com keyword em todos aceita; trocar tipo BDD -> CHECKLIST limpa a keyword na UI e persiste limpo; historico mostra o tipo de cada versao antiga corretamente (v1 BDD preservado apos virar v2 Checklist). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

jhony75 added 3 commits 2026-09-09 19:14:49 -03:00

feat: editar identidade de automação (external_key) na Library ... ff744584ff

Fecha a lacuna deixada em aberto desde o item 1 do roadmap: o backend
já suportava external_key por completo (criar/editar, unicidade
verificada, nunca roubado em duplicação), mas não existia nenhuma UI
pra editar um cenário na Library -- external_key só era setado via
mapeamento de Automation Discovery.

Adiciona "Editar identidade de automação" no menu "..." do cenário,
com o mesmo padrão de formulário inline já usado pra renomear suíte.

fix: editar só external_key/suite_id/tags não deve virar uma versão
nova do cenário -- são metadados de classificação, não uma forma
diferente de testar a mesma coisa. update_scenario_template sempre
criava uma entrada de TestScenarioTemplateVersion e incrementava
version em QUALQUER PUT, mesmo um que só mudasse a external_key --
nunca dava pra perceber isso porque não havia UI nenhuma chamando esse
endpoint até agora. Version só bump quando name/description/steps
(conteúdo de verdade) estão no payload.

feat: Shared Steps -- passo reutilizavel e versionado (item 4) ... 1b19e0d7ed

Nova biblioteca de passos (modules/shared_steps/) independente de
qualquer cenario: um SharedStep tem versao propria (SharedStepVersion
guarda TODA versao, nao so historico -- diferente do padrao de
TestScenarioTemplateVersion, porque aqui uma referencia externa
precisa resolver "o conteudo exato da versao N" de forma uniforme).

Um passo de cenario (TestStepTemplate) pode opcionalmente referenciar
um SharedStep FIXADO numa versao especifica (shared_step_id +
shared_step_version). Editar um SharedStep NUNCA muda silenciosamente
quem ja usa uma versao antiga -- description/keyword do passo sao uma
copia real da versao fixada (todo export/copia-pra-run que ja le
step.description/step.keyword funciona sem nenhuma mudanca). Upgrade
so acontece quando o payload manda um shared_step_version diferente,
explicitamente -- resolvido sempre a partir de SharedStepVersion
(nunca do SharedStep "atual" direto), entao reenviar o mesmo pin em
edicoes sem relacao nenhuma nunca faz upgrade sem querer.

Cenarios podem misturar passos soltos e passos vinculados livremente.
Deletar um SharedStep so desfaz o vinculo (SET NULL) -- o passo mantem
a ultima copia de texto que tinha, nunca é apagado.

Frontend:
- Nova tela "Shared Steps" (biblioteca propria): criar, editar (sempre
  gera versao nova), tags, "onde e usado" (com flag de desatualizado),
  comparar 2 versoes lado a lado (diff de palavras, LCS local em
  wordDiff.ts -- sem biblioteca nova).
- ScenarioBuilder ganha: inserir um Shared Step existente num passo,
  "Tornar Shared Step" (extrai o texto de um passo solto pra um
  SharedStep novo), badge de vinculo + "Atualizar pra vN" quando a
  versao fixada fica pra tras.
- Library ganha "Editar cenario" (reusa ScenarioBuilder com prefill) --
  não existia NENHUMA forma de editar passos de um cenario ja
  existente antes disso; sem essa capacidade não dava pra gerenciar
  vinculo/upgrade/desvinculo em cenarios que ja existem.

fix (achado testando): update_scenario_template sempre criava uma
versao nova em QUALQUER PUT, mesmo um que so mudasse metadado
(external_key/suite_id/tags) -- ver commit da PR #48. Sem essa
correcao, cada vinculo/upgrade de Shared Step teria gerado uma entrada
de historico espuria no cenario.

Migration: shared_steps, shared_step_versions, shared_step_tags +
2 colunas em test_step_templates. Testado upgrade/downgrade.

Verificacao: backend pytest -n auto (166 passed, 9 testes novos),
frontend tsc/lint/vitest (116 passed, 8 testes novos)/build/
build-storybook -- todos ok. Testado manualmente ponta a ponta contra
o dev real: criar Shared Step -> vincular a um cenario real -> editar
o Shared Step -> "desatualizado" aparece na leitura e na edicao ->
upgrade explicito funciona -> revertido depois.

feat: tipo de cenario -- MANUAL_STEPS/BDD/CHECKLIST/EXPLORATORY (item 5) ... 36fcbcff3e

Cenario ganha `type`, um vocabulario fechado igual ao padrao ja usado por
outcome/failure_classification (String simples + Literal no Pydantic, sem
Enum de banco -- ver schemas.ScenarioType). AUTOMATED deliberadamente NAO
e um tipo: automacao e capacidade/implementacao de um cenario, nao uma
categoria de autoria (decisao do roadmap item 5).

Auditoria antes de implementar (ver memoria eeg_qa_roadmap_2026_09) confirmou
que esse conceito nao existia em NENHUM lugar do codigo -- so um keyword
Given/When/Then opcional e sem validacao por passo. Pra evitar que o tipo
vire so um rotulo decorativo (regra explicita do roadmap: "nao adicionar
tipo que so muda aparencia"), cada tipo agora exige coerencia real com a
keyword dos passos, validada em `_validate_steps_for_type` (roda DEPOIS de
resolver eventuais Shared Steps, senao um passo vinculado poderia burlar a
regra):
- BDD exige keyword (Given/When/Then/And/But) obrigatoria em todo passo.
- CHECKLIST proibe keyword em qualquer passo.
- MANUAL_STEPS e EXPLORATORY nao restringem nada (EXPLORATORY reaproveita
  100% a lista de passos e o modelo de Run atual, so tratada como notas de
  alto nivel na UI -- decisao explicita de manter o escopo pequeno nesta
  rodada, sem redesenhar execucao).

Trocar o tipo valida os passos que JA existem mesmo quando `steps` nao e
reenviado no PUT (ex.: só mudar pra BDD sem reenviar passos ainda checa se
os passos atuais tem keyword). `type` conta como CONTEUDO pra fins de
versionamento (mesma lista de name/description/steps que ja bump a versao
e grava historico -- ver update_scenario_template), porque redefine o que
os passos do cenario significam; metadado (tags/external_key/suite_id)
continua sem versionar.

Frontend: seletor de tipo no ScenarioBuilder, com normalizacao imediata ao
trocar (BDD preenche keyword em branco com "Given", CHECKLIST limpa
keyword de todo passo) pra manter a UI sempre coerente com o que o backend
vai validar -- keyword fica escondida pra CHECKLIST e sem a opcao vazia "—"
pra BDD. Checagem espelhada no cliente antes do submit evita um
round-trip previsivel; o backend continua sendo a fonte de verdade. Badge
de tipo na Library (detalhe e historico), reaproveitando o
domainStatusVariants.ts do item 3.

Verificacao: backend pytest -n auto (172 passed, 6 testes novos), frontend
tsc/lint/vitest (125 passed, 4 testes novos)/build/build-storybook --
todos ok. Testado manualmente contra o dev real: criar cenario BDD sem
keyword em algum passo rejeita; criar com keyword em todos aceita; trocar
tipo BDD -> CHECKLIST limpa a keyword na UI e no save; historico mostra o
tipo de cada versao antiga corretamente.

Empilhado sobre a branch feature/shared-steps (item 4, PR #49, ainda nao
mergeada), que por sua vez empilha sobre feature/scenario-external-key-edit
(PR #48, ainda nao mergeada).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

jhony75 merged commit 53903744ce into develop 2026-09-09 19:32:43 -03:00

jhony75 referenced this pull request from a commit 2026-09-09 19:32:44 -03:00

Merge pull request 'feat: tipo de cenario -- MANUAL_STEPS/BDD/CHECKLIST/EXPLORATORY (item 5)' (#50) from feature/scenario-types into develop

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

jhony75/eeg-qa!50

No description provided.