mirror of
https://github.com/R0m1k3/CollectFlow.git
synced 2026-10-23 15:08:12 +02:00
feat: Add a foundational set of BMM, BMB, TEA, and Core workflows, agent definitions, and supporting templates.
This commit is contained in:
Michael committed
commit
6a0ddd7e36
724 files changed
+110361
No files matched your search
@@ -0,0 +1,143 @@
|
||||
---
|
||||
name: 'step-01-preflight-and-context'
|
||||
description: 'Verify prerequisites and load story, framework, and knowledge base'
|
||||
outputFile: '{test_artifacts}/atdd-checklist-{story_id}.md'
|
||||
nextStepFile: './step-02-generation-mode.md'
|
||||
knowledgeIndex: '{project-root}/_bmad/tea/testarch/tea-index.csv'
|
||||
---
|
||||
|
||||
# Step 1: Preflight & Context Loading
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Verify prerequisites and load all required inputs before generating failing tests.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
- 🚫 Halt if requirements are missing
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 Record outputs before proceeding
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: config, loaded artifacts, and knowledge fragments
|
||||
- Focus: this step's goal only
|
||||
- Limits: do not execute future steps
|
||||
- Dependencies: prior steps' outputs (if any)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
## 1. Prerequisites (Hard Requirements)
|
||||
|
||||
- Story approved with **clear acceptance criteria**
|
||||
- Test framework configured (`playwright.config.ts` or `cypress.config.ts`)
|
||||
- Development environment available
|
||||
|
||||
If any are missing: **HALT** and notify the user.
|
||||
|
||||
---
|
||||
|
||||
## 2. Load Story Context
|
||||
|
||||
- Read story markdown from `{story_file}` (or ask user if not provided)
|
||||
- Extract acceptance criteria and constraints
|
||||
- Identify affected components and integrations
|
||||
|
||||
---
|
||||
|
||||
## 3. Load Framework & Existing Patterns
|
||||
|
||||
- Read framework config
|
||||
- Inspect `{test_dir}` for existing test patterns, fixtures, helpers
|
||||
|
||||
## 3.5 Read TEA Config Flags
|
||||
|
||||
From `{config_source}`:
|
||||
|
||||
- `tea_use_playwright_utils`
|
||||
- `tea_browser_automation`
|
||||
|
||||
---
|
||||
|
||||
## 4. Load Knowledge Base Fragments
|
||||
|
||||
Use `{knowledgeIndex}` to load:
|
||||
|
||||
**Core (always):**
|
||||
|
||||
- `data-factories.md`
|
||||
- `component-tdd.md`
|
||||
- `test-quality.md`
|
||||
- `test-healing-patterns.md`
|
||||
- `selector-resilience.md`
|
||||
- `timing-debugging.md`
|
||||
|
||||
**Playwright Utils (if enabled):**
|
||||
|
||||
- `overview.md`, `api-request.md`, `network-recorder.md`, `auth-session.md`, `intercept-network-call.md`, `recurse.md`, `log.md`, `file-utils.md`, `network-error-monitor.md`, `fixtures-composition.md`
|
||||
|
||||
**Playwright CLI (if tea_browser_automation is "cli" or "auto"):**
|
||||
|
||||
- `playwright-cli.md`
|
||||
|
||||
**MCP Patterns (if tea_browser_automation is "mcp" or "auto"):**
|
||||
|
||||
- (existing MCP-related fragments, if any are added in future)
|
||||
|
||||
**Traditional Patterns (if utils disabled):**
|
||||
|
||||
- `fixture-architecture.md`
|
||||
- `network-first.md`
|
||||
|
||||
---
|
||||
|
||||
## 5. Confirm Inputs
|
||||
|
||||
Summarize loaded inputs and confirm with the user. Then proceed.
|
||||
|
||||
---
|
||||
|
||||
## 6. Save Progress
|
||||
|
||||
**Save this step's accumulated work to `{outputFile}`.**
|
||||
|
||||
- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-01-preflight-and-context']
|
||||
lastStep: 'step-01-preflight-and-context'
|
||||
lastSaved: '{date}'
|
||||
---
|
||||
```
|
||||
|
||||
Then write this step's output below the frontmatter.
|
||||
|
||||
- **If `{outputFile}` already exists**, update:
|
||||
- Add `'step-01-preflight-and-context'` to `stepsCompleted` array (only if not already present)
|
||||
- Set `lastStep: 'step-01-preflight-and-context'`
|
||||
- Set `lastSaved: '{date}'`
|
||||
- Append this step's output to the appropriate section.
|
||||
|
||||
Load next step: `{nextStepFile}`
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Step completed in full with required outputs
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipped sequence steps or missing outputs
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: 'step-01b-resume'
|
||||
description: 'Resume interrupted workflow from last completed step'
|
||||
outputFile: '{test_artifacts}/atdd-checklist-{story_id}.md'
|
||||
---
|
||||
|
||||
# Step 1b: Resume Workflow
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Resume an interrupted workflow by loading the existing output document, displaying progress, and routing to the next incomplete step.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Output document with progress frontmatter
|
||||
- Focus: Load progress and route to next step
|
||||
- Limits: Do not re-execute completed steps
|
||||
- Dependencies: Output document must exist from a previous run
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly.
|
||||
|
||||
### 1. Load Output Document
|
||||
|
||||
Read `{outputFile}` and parse YAML frontmatter for:
|
||||
|
||||
- `stepsCompleted` — array of completed step names
|
||||
- `lastStep` — last completed step name
|
||||
- `lastSaved` — timestamp of last save
|
||||
|
||||
**If `{outputFile}` does not exist**, display:
|
||||
|
||||
"⚠️ **No previous progress found.** There is no output document to resume from. Please use **[C] Create** to start a fresh workflow run."
|
||||
|
||||
**THEN:** Halt. Do not proceed.
|
||||
|
||||
---
|
||||
|
||||
### 2. Display Progress Dashboard
|
||||
|
||||
Display progress with ✅/⬜ indicators:
|
||||
|
||||
1. ✅/⬜ Preflight & Context (step-01-preflight-and-context)
|
||||
2. ✅/⬜ Generation Mode (step-02-generation-mode)
|
||||
3. ✅/⬜ Test Strategy (step-03-test-strategy)
|
||||
4. ✅/⬜ Generate Tests + Aggregate (step-04c-aggregate)
|
||||
5. ✅/⬜ Validate & Complete (step-05-validate-and-complete)
|
||||
|
||||
---
|
||||
|
||||
### 3. Route to Next Step
|
||||
|
||||
Based on `lastStep`, load the next incomplete step:
|
||||
|
||||
- `'step-01-preflight-and-context'` → load `./step-02-generation-mode.md`
|
||||
- `'step-02-generation-mode'` → load `./step-03-test-strategy.md`
|
||||
- `'step-03-test-strategy'` → load `./step-04-generate-tests.md`
|
||||
- `'step-04c-aggregate'` → load `./step-05-validate-and-complete.md`
|
||||
- `'step-05-validate-and-complete'` → **Workflow already complete.** Display: "✅ **All steps completed.** Use **[V] Validate** to review outputs or **[E] Edit** to make revisions." Then halt.
|
||||
|
||||
**If `lastStep` does not match any value above**, display: "⚠️ **Unknown progress state** (`lastStep`: {lastStep}). Please use **[C] Create** to start fresh." Then halt.
|
||||
|
||||
**Otherwise**, load the identified step file, read completely, and execute.
|
||||
|
||||
The existing content in `{outputFile}` provides context from previously completed steps.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Output document loaded and parsed correctly
|
||||
- Progress dashboard displayed accurately
|
||||
- Routed to correct next step
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not loading output document
|
||||
- Incorrect progress display
|
||||
- Routing to wrong step
|
||||
|
||||
**Master Rule:** Resume MUST route to the exact next incomplete step. Never re-execute completed steps.
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
name: 'step-02-generation-mode'
|
||||
description: 'Choose AI generation or recording mode'
|
||||
outputFile: '{test_artifacts}/atdd-checklist-{story_id}.md'
|
||||
nextStepFile: './step-03-test-strategy.md'
|
||||
---
|
||||
|
||||
# Step 2: Generation Mode Selection
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Choose the appropriate generation mode for ATDD tests.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 Record outputs before proceeding
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: config, loaded artifacts, and knowledge fragments
|
||||
- Focus: this step's goal only
|
||||
- Limits: do not execute future steps
|
||||
- Dependencies: prior steps' outputs (if any)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
## 1. Default Mode: AI Generation
|
||||
|
||||
Use AI generation when:
|
||||
|
||||
- Acceptance criteria are clear
|
||||
- Scenarios are standard (CRUD, auth, API, navigation)
|
||||
|
||||
Proceed directly to test strategy if this applies.
|
||||
|
||||
---
|
||||
|
||||
## 2. Optional Mode: Recording (Complex UI)
|
||||
|
||||
Use recording when UI interactions need live browser verification.
|
||||
|
||||
**Tool selection based on `config.tea_browser_automation`:**
|
||||
|
||||
If `auto`:
|
||||
|
||||
> **Note:** `${timestamp}` is a placeholder the agent should replace with a unique value (e.g., epoch seconds) for session isolation.
|
||||
|
||||
- **Simple recording** (snapshot selectors, capture structure): Use CLI
|
||||
- `playwright-cli -s=tea-atdd-${timestamp} open <url>` → `playwright-cli -s=tea-atdd-${timestamp} snapshot` → extract refs
|
||||
- **Complex recording** (drag/drop, wizards, multi-step state): Use MCP
|
||||
- Full browser automation with rich tool semantics
|
||||
- **Fallback:** If preferred tool unavailable, use the other; if neither, skip recording
|
||||
|
||||
If `cli`:
|
||||
|
||||
- Use Playwright CLI for all recording
|
||||
- `playwright-cli -s=tea-atdd-${timestamp} open <url>`, `snapshot`, `screenshot`, `click <ref>`, etc.
|
||||
|
||||
If `mcp`:
|
||||
|
||||
- Use Playwright MCP tools for all recording (current behavior)
|
||||
- Confirm MCP availability, record selectors and interactions
|
||||
|
||||
If `none`:
|
||||
|
||||
- Skip recording mode entirely, use AI generation from documentation
|
||||
|
||||
---
|
||||
|
||||
## 3. Confirm Mode
|
||||
|
||||
State the chosen mode and why. Then proceed.
|
||||
|
||||
---
|
||||
|
||||
## 4. Save Progress
|
||||
|
||||
**Save this step's accumulated work to `{outputFile}`.**
|
||||
|
||||
- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-02-generation-mode']
|
||||
lastStep: 'step-02-generation-mode'
|
||||
lastSaved: '{date}'
|
||||
---
|
||||
```
|
||||
|
||||
Then write this step's output below the frontmatter.
|
||||
|
||||
- **If `{outputFile}` already exists**, update:
|
||||
- Add `'step-02-generation-mode'` to `stepsCompleted` array (only if not already present)
|
||||
- Set `lastStep: 'step-02-generation-mode'`
|
||||
- Set `lastSaved: '{date}'`
|
||||
- Append this step's output to the appropriate section.
|
||||
|
||||
Load next step: `{nextStepFile}`
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Step completed in full with required outputs
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipped sequence steps or missing outputs
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
@@ -0,0 +1,101 @@
|
||||
---
|
||||
name: 'step-03-test-strategy'
|
||||
description: 'Map acceptance criteria to test levels and priorities'
|
||||
outputFile: '{test_artifacts}/atdd-checklist-{story_id}.md'
|
||||
nextStepFile: './step-04-generate-tests.md'
|
||||
---
|
||||
|
||||
# Step 3: Test Strategy
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Translate acceptance criteria into a prioritized, level-appropriate test plan.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
- 🚫 Avoid duplicate coverage across levels
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 Record outputs before proceeding
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: config, loaded artifacts, and knowledge fragments
|
||||
- Focus: this step's goal only
|
||||
- Limits: do not execute future steps
|
||||
- Dependencies: prior steps' outputs (if any)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
## 1. Map Acceptance Criteria
|
||||
|
||||
- Convert each acceptance criterion into test scenarios
|
||||
- Include negative and edge cases where risk is high
|
||||
|
||||
---
|
||||
|
||||
## 2. Select Test Levels
|
||||
|
||||
Choose the best level per scenario:
|
||||
|
||||
- **E2E** for critical user journeys
|
||||
- **API** for business logic and service contracts
|
||||
- **Component** for UI behavior
|
||||
|
||||
---
|
||||
|
||||
## 3. Prioritize Tests
|
||||
|
||||
Assign P0–P3 priorities using risk and business impact.
|
||||
|
||||
---
|
||||
|
||||
## 4. Confirm Red Phase Requirements
|
||||
|
||||
Ensure all tests are designed to **fail before implementation** (TDD red phase).
|
||||
|
||||
---
|
||||
|
||||
## 5. Save Progress
|
||||
|
||||
**Save this step's accumulated work to `{outputFile}`.**
|
||||
|
||||
- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-03-test-strategy']
|
||||
lastStep: 'step-03-test-strategy'
|
||||
lastSaved: '{date}'
|
||||
---
|
||||
```
|
||||
|
||||
Then write this step's output below the frontmatter.
|
||||
|
||||
- **If `{outputFile}` already exists**, update:
|
||||
- Add `'step-03-test-strategy'` to `stepsCompleted` array (only if not already present)
|
||||
- Set `lastStep: 'step-03-test-strategy'`
|
||||
- Set `lastSaved: '{date}'`
|
||||
- Append this step's output to the appropriate section.
|
||||
|
||||
Load next step: `{nextStepFile}`
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Step completed in full with required outputs
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipped sequence steps or missing outputs
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
@@ -0,0 +1,229 @@
|
||||
---
|
||||
name: 'step-04-generate-tests'
|
||||
description: 'Orchestrate parallel FAILING test generation (TDD red phase)'
|
||||
nextStepFile: './step-04c-aggregate.md'
|
||||
---
|
||||
|
||||
# Step 4: Orchestrate Parallel FAILING Test Generation
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Launch parallel subprocesses to generate FAILING API and E2E tests simultaneously (TDD RED PHASE) for maximum performance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
- ✅ Launch TWO subprocesses in PARALLEL
|
||||
- ✅ Generate FAILING tests only (TDD red phase)
|
||||
- ✅ Wait for BOTH subprocesses to complete
|
||||
- ❌ Do NOT generate sequential tests (use subprocesses)
|
||||
- ❌ Do NOT generate passing tests (this is red phase)
|
||||
- ❌ Do NOT proceed until both subprocesses finish
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 Wait for subprocess outputs
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: config, acceptance criteria from Step 1, test strategy from Step 3
|
||||
- Focus: subprocess orchestration only
|
||||
- Limits: do not generate tests directly (delegate to subprocesses)
|
||||
- Dependencies: Steps 1-3 outputs
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
### 1. Prepare Subprocess Inputs
|
||||
|
||||
**Generate unique timestamp** for temp file naming:
|
||||
|
||||
```javascript
|
||||
const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
|
||||
```
|
||||
|
||||
**Prepare input context for both subprocesses:**
|
||||
|
||||
```javascript
|
||||
const subprocessContext = {
|
||||
story_acceptance_criteria: /* from Step 1 */,
|
||||
test_strategy: /* from Step 3 */,
|
||||
knowledge_fragments_loaded: /* list of fragments */,
|
||||
config: {
|
||||
test_framework: config.test_framework,
|
||||
use_playwright_utils: config.tea_use_playwright_utils,
|
||||
browser_automation: config.tea_browser_automation
|
||||
},
|
||||
timestamp: timestamp
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Launch Subprocess A: Failing API Test Generation
|
||||
|
||||
**Launch subprocess in parallel:**
|
||||
|
||||
- **Subprocess File:** `./step-04a-subprocess-api-failing.md`
|
||||
- **Output File:** `/tmp/tea-atdd-api-tests-${timestamp}.json`
|
||||
- **Context:** Pass `subprocessContext`
|
||||
- **Execution:** PARALLEL (non-blocking)
|
||||
- **TDD Phase:** RED (failing tests)
|
||||
|
||||
**System Action:**
|
||||
|
||||
```
|
||||
🚀 Launching Subprocess A: FAILING API Test Generation (RED PHASE)
|
||||
📝 Output: /tmp/tea-atdd-api-tests-${timestamp}.json
|
||||
🔴 TDD Phase: RED (tests will fail until feature implemented)
|
||||
⏳ Status: Running in parallel...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Launch Subprocess B: Failing E2E Test Generation
|
||||
|
||||
**Launch subprocess in parallel:**
|
||||
|
||||
- **Subprocess File:** `./step-04b-subprocess-e2e-failing.md`
|
||||
- **Output File:** `/tmp/tea-atdd-e2e-tests-${timestamp}.json`
|
||||
- **Context:** Pass `subprocessContext`
|
||||
- **Execution:** PARALLEL (non-blocking)
|
||||
- **TDD Phase:** RED (failing tests)
|
||||
|
||||
**System Action:**
|
||||
|
||||
```
|
||||
🚀 Launching Subprocess B: FAILING E2E Test Generation (RED PHASE)
|
||||
📝 Output: /tmp/tea-atdd-e2e-tests-${timestamp}.json
|
||||
🔴 TDD Phase: RED (tests will fail until feature implemented)
|
||||
⏳ Status: Running in parallel...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Wait for Both Subprocesses to Complete
|
||||
|
||||
**Monitor subprocess execution:**
|
||||
|
||||
```
|
||||
⏳ Waiting for subprocesses to complete...
|
||||
├── Subprocess A (API RED): Running... ⟳
|
||||
└── Subprocess B (E2E RED): Running... ⟳
|
||||
|
||||
[... time passes ...]
|
||||
|
||||
├── Subprocess A (API RED): Complete ✅
|
||||
└── Subprocess B (E2E RED): Complete ✅
|
||||
|
||||
✅ All subprocesses completed successfully!
|
||||
```
|
||||
|
||||
**Verify both outputs exist:**
|
||||
|
||||
```javascript
|
||||
const apiOutputExists = fs.existsSync(`/tmp/tea-atdd-api-tests-${timestamp}.json`);
|
||||
const e2eOutputExists = fs.existsSync(`/tmp/tea-atdd-e2e-tests-${timestamp}.json`);
|
||||
|
||||
if (!apiOutputExists || !e2eOutputExists) {
|
||||
throw new Error('One or both subprocess outputs missing!');
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. TDD Red Phase Report
|
||||
|
||||
**Display TDD status:**
|
||||
|
||||
```
|
||||
🔴 TDD RED PHASE: Failing Tests Generated
|
||||
|
||||
✅ Both subprocesses completed:
|
||||
- API Tests: Generated with test.skip()
|
||||
- E2E Tests: Generated with test.skip()
|
||||
|
||||
📋 All tests assert EXPECTED behavior
|
||||
📋 All tests will FAIL until feature implemented
|
||||
📋 This is INTENTIONAL (TDD red phase)
|
||||
|
||||
Next: Aggregation will verify TDD compliance
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. Performance Report
|
||||
|
||||
**Display performance metrics:**
|
||||
|
||||
```
|
||||
🚀 Performance Report:
|
||||
- Execution Mode: PARALLEL (2 subprocesses)
|
||||
- API Test Generation: ~X minutes
|
||||
- E2E Test Generation: ~Y minutes
|
||||
- Total Elapsed: ~max(X, Y) minutes
|
||||
- Sequential Would Take: ~(X + Y) minutes
|
||||
- Performance Gain: ~50% faster!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Proceed to Aggregation
|
||||
|
||||
**Load aggregation step:**
|
||||
Load next step: `{nextStepFile}`
|
||||
|
||||
The aggregation step (4C) will:
|
||||
|
||||
- Read both subprocess outputs
|
||||
- Verify TDD red phase compliance (all tests have test.skip())
|
||||
- Write all test files to disk
|
||||
- Generate ATDD checklist
|
||||
- Calculate summary statistics
|
||||
|
||||
---
|
||||
|
||||
## EXIT CONDITION
|
||||
|
||||
Proceed to Step 4C (Aggregation) when:
|
||||
|
||||
- ✅ Subprocess A (API failing tests) completed successfully
|
||||
- ✅ Subprocess B (E2E failing tests) completed successfully
|
||||
- ✅ Both output files exist and are valid JSON
|
||||
- ✅ TDD red phase status reported
|
||||
|
||||
**Do NOT proceed if:**
|
||||
|
||||
- ❌ One or both subprocesses failed
|
||||
- ❌ Output files missing or corrupted
|
||||
- ❌ Subprocess generated passing tests (wrong - must be failing)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Both subprocesses launched successfully
|
||||
- Both subprocesses completed without errors
|
||||
- Output files generated and valid
|
||||
- Tests generated with test.skip() (TDD red phase)
|
||||
- Parallel execution achieved ~50% performance gain
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Failed to launch subprocesses
|
||||
- One or both subprocesses failed
|
||||
- Output files missing or invalid
|
||||
- Tests generated without test.skip() (wrong phase)
|
||||
- Attempted sequential generation instead of parallel
|
||||
|
||||
**Master Rule:** TDD RED PHASE requires FAILING tests (with test.skip()). Parallel subprocess execution is MANDATORY for performance.
|
||||
@@ -0,0 +1,215 @@
|
||||
---
|
||||
name: 'step-04a-subprocess-api-failing'
|
||||
description: 'Subprocess: Generate FAILING API tests (TDD red phase)'
|
||||
subprocess: true
|
||||
outputFile: '/tmp/tea-atdd-api-tests-{{timestamp}}.json'
|
||||
---
|
||||
|
||||
# Subprocess 4A: Generate Failing API Tests (TDD Red Phase)
|
||||
|
||||
## SUBPROCESS CONTEXT
|
||||
|
||||
This is an **isolated subprocess** running in parallel with E2E failing test generation.
|
||||
|
||||
**What you have from parent workflow:**
|
||||
|
||||
- Story acceptance criteria from Step 1
|
||||
- Test strategy and scenarios from Step 3
|
||||
- Knowledge fragments loaded: api-request, data-factories, api-testing-patterns
|
||||
- Config: test framework, Playwright Utils enabled/disabled
|
||||
|
||||
**Your task:** Generate API tests that will FAIL because the feature is not implemented yet (TDD RED PHASE).
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read this entire subprocess file before acting
|
||||
- ✅ Generate FAILING API tests ONLY
|
||||
- ✅ Tests MUST fail when run (feature not implemented yet)
|
||||
- ✅ Output structured JSON to temp file
|
||||
- ✅ Follow knowledge fragment patterns
|
||||
- ❌ Do NOT generate E2E tests (that's subprocess 4B)
|
||||
- ❌ Do NOT generate passing tests (this is TDD red phase)
|
||||
- ❌ Do NOT run tests (that's step 5)
|
||||
|
||||
---
|
||||
|
||||
## SUBPROCESS TASK
|
||||
|
||||
### 1. Identify API Endpoints from Acceptance Criteria
|
||||
|
||||
From the story acceptance criteria (Step 1 output), identify:
|
||||
|
||||
- Which API endpoints will be created for this story
|
||||
- Expected request/response contracts
|
||||
- Authentication requirements
|
||||
- Expected status codes and error scenarios
|
||||
|
||||
**Example Acceptance Criteria:**
|
||||
|
||||
```
|
||||
Story: User Registration
|
||||
- As a user, I can POST to /api/users/register with email and password
|
||||
- System returns 201 Created with user object
|
||||
- System returns 400 Bad Request if email already exists
|
||||
- System returns 422 Unprocessable Entity if validation fails
|
||||
```
|
||||
|
||||
### 2. Generate FAILING API Test Files
|
||||
|
||||
For each API endpoint, create test file in `tests/api/[feature].spec.ts`:
|
||||
|
||||
**Test Structure (ATDD - Red Phase):**
|
||||
|
||||
```typescript
|
||||
import { test, expect } from '@playwright/test';
|
||||
// If Playwright Utils enabled:
|
||||
// import { apiRequest } from '@playwright-utils/api';
|
||||
|
||||
test.describe('[Story Name] API Tests (ATDD)', () => {
|
||||
test.skip('[P0] should register new user successfully', async ({ request }) => {
|
||||
// THIS TEST WILL FAIL - Endpoint not implemented yet
|
||||
const response = await request.post('/api/users/register', {
|
||||
data: {
|
||||
email: 'newuser@example.com',
|
||||
password: 'SecurePass123!',
|
||||
},
|
||||
});
|
||||
|
||||
// Expect 201 but will get 404 (endpoint doesn't exist)
|
||||
expect(response.status()).toBe(201);
|
||||
|
||||
const user = await response.json();
|
||||
expect(user).toMatchObject({
|
||||
id: expect.any(Number),
|
||||
email: 'newuser@example.com',
|
||||
});
|
||||
});
|
||||
|
||||
test.skip('[P1] should return 400 if email exists', async ({ request }) => {
|
||||
// THIS TEST WILL FAIL - Endpoint not implemented yet
|
||||
const response = await request.post('/api/users/register', {
|
||||
data: {
|
||||
email: 'existing@example.com',
|
||||
password: 'SecurePass123!',
|
||||
},
|
||||
});
|
||||
|
||||
expect(response.status()).toBe(400);
|
||||
const error = await response.json();
|
||||
expect(error.message).toContain('Email already exists');
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**CRITICAL ATDD Requirements:**
|
||||
|
||||
- ✅ Use `test.skip()` to mark tests as intentionally failing (red phase)
|
||||
- ✅ Write assertions for EXPECTED behavior (even though not implemented)
|
||||
- ✅ Use realistic test data (not placeholder data)
|
||||
- ✅ Test both happy path and error scenarios from acceptance criteria
|
||||
- ✅ Use `apiRequest()` helper if Playwright Utils enabled
|
||||
- ✅ Use data factories for test data (from data-factories fragment)
|
||||
- ✅ Include priority tags [P0], [P1], [P2], [P3]
|
||||
|
||||
**Why test.skip():**
|
||||
|
||||
- Tests are written correctly for EXPECTED behavior
|
||||
- But we know they'll fail because feature isn't implemented
|
||||
- `test.skip()` documents this is intentional (TDD red phase)
|
||||
- Once feature is implemented, remove `test.skip()` to verify green phase
|
||||
|
||||
### 3. Track Fixture Needs
|
||||
|
||||
Identify fixtures needed for API tests:
|
||||
|
||||
- Authentication fixtures (if endpoints require auth)
|
||||
- Data factories (user data, etc.)
|
||||
- API client configurations
|
||||
|
||||
**Do NOT create fixtures yet** - just track what's needed for aggregation step.
|
||||
|
||||
---
|
||||
|
||||
## OUTPUT FORMAT
|
||||
|
||||
Write JSON to temp file: `/tmp/tea-atdd-api-tests-{{timestamp}}.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"subprocess": "atdd-api-tests",
|
||||
"tests": [
|
||||
{
|
||||
"file": "tests/api/user-registration.spec.ts",
|
||||
"content": "[full TypeScript test file content with test.skip()]",
|
||||
"description": "ATDD API tests for user registration (RED PHASE)",
|
||||
"expected_to_fail": true,
|
||||
"acceptance_criteria_covered": [
|
||||
"User can register with email/password",
|
||||
"System returns 201 on success",
|
||||
"System returns 400 if email exists"
|
||||
],
|
||||
"priority_coverage": {
|
||||
"P0": 1,
|
||||
"P1": 2,
|
||||
"P2": 0,
|
||||
"P3": 0
|
||||
}
|
||||
}
|
||||
],
|
||||
"fixture_needs": ["userDataFactory"],
|
||||
"knowledge_fragments_used": ["api-request", "data-factories", "api-testing-patterns"],
|
||||
"test_count": 3,
|
||||
"tdd_phase": "RED",
|
||||
"summary": "Generated 3 FAILING API tests for user registration story"
|
||||
}
|
||||
```
|
||||
|
||||
**On Error:**
|
||||
|
||||
```json
|
||||
{
|
||||
"success": false,
|
||||
"subprocess": "atdd-api-tests",
|
||||
"error": "Error message describing what went wrong",
|
||||
"partial_output": {
|
||||
/* any tests generated before error */
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## EXIT CONDITION
|
||||
|
||||
Subprocess completes when:
|
||||
|
||||
- ✅ All API endpoints from acceptance criteria have test files
|
||||
- ✅ All tests use `test.skip()` (documented failing tests)
|
||||
- ✅ All tests assert EXPECTED behavior (not placeholder assertions)
|
||||
- ✅ JSON output written to temp file
|
||||
- ✅ Fixture needs tracked
|
||||
|
||||
**Subprocess terminates here.** Parent workflow will read output and proceed to aggregation.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SUBPROCESS SUCCESS METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All API tests generated with test.skip()
|
||||
- Tests assert expected behavior (not placeholders)
|
||||
- JSON output valid and complete
|
||||
- No E2E/component/unit tests included (out of scope)
|
||||
- Tests follow knowledge fragment patterns
|
||||
|
||||
### ❌ FAILURE:
|
||||
|
||||
- Generated passing tests (wrong - this is RED phase)
|
||||
- Tests without test.skip() (will break CI)
|
||||
- Placeholder assertions (expect(true).toBe(true))
|
||||
- Did not follow knowledge fragment patterns
|
||||
- Invalid or missing JSON output
|
||||
@@ -0,0 +1,244 @@
|
||||
---
|
||||
name: 'step-04b-subprocess-e2e-failing'
|
||||
description: 'Subprocess: Generate FAILING E2E tests (TDD red phase)'
|
||||
subprocess: true
|
||||
outputFile: '/tmp/tea-atdd-e2e-tests-{{timestamp}}.json'
|
||||
---
|
||||
|
||||
# Subprocess 4B: Generate Failing E2E Tests (TDD Red Phase)
|
||||
|
||||
## SUBPROCESS CONTEXT
|
||||
|
||||
This is an **isolated subprocess** running in parallel with API failing test generation.
|
||||
|
||||
**What you have from parent workflow:**
|
||||
|
||||
- Story acceptance criteria from Step 1
|
||||
- Test strategy and user journey scenarios from Step 3
|
||||
- Knowledge fragments loaded: fixture-architecture, network-first, selector-resilience
|
||||
- Config: test framework, Playwright Utils enabled/disabled
|
||||
|
||||
**Your task:** Generate E2E tests that will FAIL because the feature UI is not implemented yet (TDD RED PHASE).
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read this entire subprocess file before acting
|
||||
- ✅ Generate FAILING E2E tests ONLY
|
||||
- ✅ Tests MUST fail when run (UI not implemented yet)
|
||||
- ✅ Output structured JSON to temp file
|
||||
- ✅ Follow knowledge fragment patterns
|
||||
- ❌ Do NOT generate API tests (that's subprocess 4A)
|
||||
- ❌ Do NOT generate passing tests (this is TDD red phase)
|
||||
- ❌ Do NOT run tests (that's step 5)
|
||||
|
||||
---
|
||||
|
||||
## SUBPROCESS TASK
|
||||
|
||||
### 1. Identify User Journeys from Acceptance Criteria
|
||||
|
||||
From the story acceptance criteria (Step 1 output), identify:
|
||||
|
||||
- Which UI flows will be created for this story
|
||||
- User interactions required
|
||||
- Expected visual states
|
||||
- Success/error messages expected
|
||||
|
||||
**Example Acceptance Criteria:**
|
||||
|
||||
```
|
||||
Story: User Registration
|
||||
- As a user, I can navigate to /register page
|
||||
- I can fill in email and password fields
|
||||
- I can click "Register" button
|
||||
- System shows success message and redirects to dashboard
|
||||
- System shows error if email already exists
|
||||
```
|
||||
|
||||
### 2. Browser Interaction (Selector Verification)
|
||||
|
||||
**Automation mode:** `config.tea_browser_automation`
|
||||
|
||||
If `auto` (fall back to MCP if CLI unavailable; if neither available, generate from best practices):
|
||||
|
||||
- Open the target page first, then verify selectors with a snapshot:
|
||||
`playwright-cli -s=tea-atdd-{{timestamp}} open <target_url>`
|
||||
`playwright-cli -s=tea-atdd-{{timestamp}} snapshot` → map refs to Playwright locators
|
||||
- ref `{role: "button", name: "Submit"}` → `page.getByRole('button', { name: 'Submit' })`
|
||||
- ref `{role: "textbox", name: "Email"}` → `page.getByRole('textbox', { name: 'Email' })`
|
||||
- `playwright-cli -s=tea-atdd-{{timestamp}} close` when done
|
||||
|
||||
If `cli` (CLI only — do NOT fall back to MCP; generate from best practices if CLI unavailable):
|
||||
|
||||
- Open the target page first, then verify selectors with a snapshot:
|
||||
`playwright-cli -s=tea-atdd-{{timestamp}} open <target_url>`
|
||||
`playwright-cli -s=tea-atdd-{{timestamp}} snapshot` → map refs to Playwright locators
|
||||
- ref `{role: "button", name: "Submit"}` → `page.getByRole('button', { name: 'Submit' })`
|
||||
- ref `{role: "textbox", name: "Email"}` → `page.getByRole('textbox', { name: 'Email' })`
|
||||
- `playwright-cli -s=tea-atdd-{{timestamp}} close` when done
|
||||
|
||||
> **Session Hygiene:** Always close sessions using `playwright-cli -s=tea-atdd-{{timestamp}} close`. Do NOT use `close-all` — it kills every session on the machine and breaks parallel execution.
|
||||
|
||||
If `mcp`:
|
||||
|
||||
- Use MCP tools for selector verification (current behavior)
|
||||
|
||||
If `none`:
|
||||
|
||||
- Generate selectors from best practices without browser verification
|
||||
|
||||
### 3. Generate FAILING E2E Test Files
|
||||
|
||||
For each user journey, create test file in `tests/e2e/[feature].spec.ts`:
|
||||
|
||||
**Test Structure (ATDD - Red Phase):**
|
||||
|
||||
```typescript
|
||||
import { test, expect } from '@playwright/test';
|
||||
|
||||
test.describe('[Story Name] E2E User Journey (ATDD)', () => {
|
||||
test.skip('[P0] should complete user registration successfully', async ({ page }) => {
|
||||
// THIS TEST WILL FAIL - UI not implemented yet
|
||||
await page.goto('/register');
|
||||
|
||||
// Expect registration form but will get 404 or missing elements
|
||||
await page.fill('[name="email"]', 'newuser@example.com');
|
||||
await page.fill('[name="password"]', 'SecurePass123!');
|
||||
await page.click('button:has-text("Register")');
|
||||
|
||||
// Expect success message and redirect
|
||||
await expect(page.getByText('Registration successful!')).toBeVisible();
|
||||
await page.waitForURL('/dashboard');
|
||||
});
|
||||
|
||||
test.skip('[P1] should show error if email exists', async ({ page }) => {
|
||||
// THIS TEST WILL FAIL - UI not implemented yet
|
||||
await page.goto('/register');
|
||||
|
||||
await page.fill('[name="email"]', 'existing@example.com');
|
||||
await page.fill('[name="password"]', 'SecurePass123!');
|
||||
await page.click('button:has-text("Register")');
|
||||
|
||||
// Expect error message
|
||||
await expect(page.getByText('Email already exists')).toBeVisible();
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**CRITICAL ATDD Requirements:**
|
||||
|
||||
- ✅ Use `test.skip()` to mark tests as intentionally failing (red phase)
|
||||
- ✅ Write assertions for EXPECTED UI behavior (even though not implemented)
|
||||
- ✅ Use resilient selectors: getByRole, getByText, getByLabel (from selector-resilience)
|
||||
- ✅ Follow network-first patterns if API calls involved (from network-first)
|
||||
- ✅ Test complete user journeys from acceptance criteria
|
||||
- ✅ Include priority tags [P0], [P1], [P2], [P3]
|
||||
- ✅ Use proper TypeScript types
|
||||
- ✅ Deterministic waits (no hard sleeps)
|
||||
|
||||
**Why test.skip():**
|
||||
|
||||
- Tests are written correctly for EXPECTED UI behavior
|
||||
- But we know they'll fail because UI isn't implemented
|
||||
- `test.skip()` documents this is intentional (TDD red phase)
|
||||
- Once UI is implemented, remove `test.skip()` to verify green phase
|
||||
|
||||
### 4. Track Fixture Needs
|
||||
|
||||
Identify fixtures needed for E2E tests:
|
||||
|
||||
- Authentication fixtures (if journey requires logged-in state)
|
||||
- Network mocks (if API calls involved)
|
||||
- Test data fixtures
|
||||
|
||||
**Do NOT create fixtures yet** - just track what's needed for aggregation step.
|
||||
|
||||
---
|
||||
|
||||
## OUTPUT FORMAT
|
||||
|
||||
Write JSON to temp file: `/tmp/tea-atdd-e2e-tests-{{timestamp}}.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"subprocess": "atdd-e2e-tests",
|
||||
"tests": [
|
||||
{
|
||||
"file": "tests/e2e/user-registration.spec.ts",
|
||||
"content": "[full TypeScript test file content with test.skip()]",
|
||||
"description": "ATDD E2E tests for user registration journey (RED PHASE)",
|
||||
"expected_to_fail": true,
|
||||
"acceptance_criteria_covered": [
|
||||
"User can navigate to /register",
|
||||
"User can fill registration form",
|
||||
"System shows success message on registration",
|
||||
"System shows error if email exists"
|
||||
],
|
||||
"priority_coverage": {
|
||||
"P0": 1,
|
||||
"P1": 1,
|
||||
"P2": 0,
|
||||
"P3": 0
|
||||
}
|
||||
}
|
||||
],
|
||||
"fixture_needs": ["registrationPageMock"],
|
||||
"knowledge_fragments_used": ["fixture-architecture", "network-first", "selector-resilience"],
|
||||
"test_count": 2,
|
||||
"tdd_phase": "RED",
|
||||
"summary": "Generated 2 FAILING E2E tests for user registration story"
|
||||
}
|
||||
```
|
||||
|
||||
**On Error:**
|
||||
|
||||
```json
|
||||
{
|
||||
"success": false,
|
||||
"subprocess": "atdd-e2e-tests",
|
||||
"error": "Error message describing what went wrong",
|
||||
"partial_output": {
|
||||
/* any tests generated before error */
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## EXIT CONDITION
|
||||
|
||||
Subprocess completes when:
|
||||
|
||||
- ✅ All user journeys from acceptance criteria have test files
|
||||
- ✅ All tests use `test.skip()` (documented failing tests)
|
||||
- ✅ All tests assert EXPECTED UI behavior (not placeholder assertions)
|
||||
- ✅ Resilient selectors used (getByRole, getByText)
|
||||
- ✅ JSON output written to temp file
|
||||
- ✅ Fixture needs tracked
|
||||
|
||||
**Subprocess terminates here.** Parent workflow will read output and proceed to aggregation.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SUBPROCESS SUCCESS METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All E2E tests generated with test.skip()
|
||||
- Tests assert expected UI behavior (not placeholders)
|
||||
- Resilient selectors used (getByRole, getByText)
|
||||
- JSON output valid and complete
|
||||
- No API/component/unit tests included (out of scope)
|
||||
- Tests follow knowledge fragment patterns
|
||||
|
||||
### ❌ FAILURE:
|
||||
|
||||
- Generated passing tests (wrong - this is RED phase)
|
||||
- Tests without test.skip() (will break CI)
|
||||
- Placeholder assertions (expect(true).toBe(true))
|
||||
- Brittle selectors used (CSS classes, XPath)
|
||||
- Did not follow knowledge fragment patterns
|
||||
- Invalid or missing JSON output
|
||||
@@ -0,0 +1,354 @@
|
||||
---
|
||||
name: 'step-04c-aggregate'
|
||||
description: 'Aggregate subprocess outputs and complete ATDD test infrastructure'
|
||||
outputFile: '{test_artifacts}/atdd-checklist-{story_id}.md'
|
||||
nextStepFile: './step-05-validate-and-complete.md'
|
||||
---
|
||||
|
||||
# Step 4C: Aggregate ATDD Test Generation Results
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Read outputs from parallel subprocesses (API + E2E failing test generation), aggregate results, verify TDD red phase compliance, and create supporting infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
- ✅ Read subprocess outputs from temp files
|
||||
- ✅ Verify all tests are marked with test.skip() (TDD red phase)
|
||||
- ✅ Generate shared fixtures based on fixture needs
|
||||
- ✅ Write all generated test files to disk
|
||||
- ❌ Do NOT remove test.skip() (that's done after feature implementation)
|
||||
- ❌ Do NOT run tests yet (that's step 5 - verify they fail)
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 Record outputs before proceeding
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: config, subprocess outputs from temp files
|
||||
- Focus: aggregation and TDD validation
|
||||
- Limits: do not execute future steps
|
||||
- Dependencies: Step 4A and 4B subprocess outputs
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
### 1. Read Subprocess Outputs
|
||||
|
||||
**Read API test subprocess output:**
|
||||
|
||||
```javascript
|
||||
const apiTestsPath = '/tmp/tea-atdd-api-tests-{{timestamp}}.json';
|
||||
const apiTestsOutput = JSON.parse(fs.readFileSync(apiTestsPath, 'utf8'));
|
||||
```
|
||||
|
||||
**Read E2E test subprocess output:**
|
||||
|
||||
```javascript
|
||||
const e2eTestsPath = '/tmp/tea-atdd-e2e-tests-{{timestamp}}.json';
|
||||
const e2eTestsOutput = JSON.parse(fs.readFileSync(e2eTestsPath, 'utf8'));
|
||||
```
|
||||
|
||||
**Verify both subprocesses succeeded:**
|
||||
|
||||
- Check `apiTestsOutput.success === true`
|
||||
- Check `e2eTestsOutput.success === true`
|
||||
- If either failed, report error and stop (don't proceed)
|
||||
|
||||
---
|
||||
|
||||
### 2. Verify TDD Red Phase Compliance
|
||||
|
||||
**CRITICAL TDD Validation:**
|
||||
|
||||
**Check API tests:**
|
||||
|
||||
```javascript
|
||||
apiTestsOutput.tests.forEach((test) => {
|
||||
// Verify test.skip() is present
|
||||
if (!test.content.includes('test.skip(')) {
|
||||
throw new Error(`ATDD ERROR: ${test.file} missing test.skip() - tests MUST be skipped in red phase!`);
|
||||
}
|
||||
|
||||
// Verify not placeholder assertions
|
||||
if (test.content.includes('expect(true).toBe(true)')) {
|
||||
throw new Error(`ATDD ERROR: ${test.file} has placeholder assertions - must assert EXPECTED behavior!`);
|
||||
}
|
||||
|
||||
// Verify expected_to_fail flag
|
||||
if (!test.expected_to_fail) {
|
||||
throw new Error(`ATDD ERROR: ${test.file} not marked as expected_to_fail!`);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
**Check E2E tests:**
|
||||
|
||||
```javascript
|
||||
e2eTestsOutput.tests.forEach((test) => {
|
||||
// Same validation as API tests
|
||||
if (!test.content.includes('test.skip(')) {
|
||||
throw new Error(`ATDD ERROR: ${test.file} missing test.skip() - tests MUST be skipped in red phase!`);
|
||||
}
|
||||
|
||||
if (test.content.includes('expect(true).toBe(true)')) {
|
||||
throw new Error(`ATDD ERROR: ${test.file} has placeholder assertions!`);
|
||||
}
|
||||
|
||||
if (!test.expected_to_fail) {
|
||||
throw new Error(`ATDD ERROR: ${test.file} not marked as expected_to_fail!`);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
**If validation passes:**
|
||||
|
||||
```
|
||||
✅ TDD Red Phase Validation: PASS
|
||||
- All tests use test.skip()
|
||||
- All tests assert expected behavior (not placeholders)
|
||||
- All tests marked as expected_to_fail
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Write All Test Files to Disk
|
||||
|
||||
**Write API test files:**
|
||||
|
||||
```javascript
|
||||
apiTestsOutput.tests.forEach((test) => {
|
||||
fs.writeFileSync(test.file, test.content, 'utf8');
|
||||
console.log(`✅ Created (RED): ${test.file}`);
|
||||
});
|
||||
```
|
||||
|
||||
**Write E2E test files:**
|
||||
|
||||
```javascript
|
||||
e2eTestsOutput.tests.forEach((test) => {
|
||||
fs.writeFileSync(test.file, test.content, 'utf8');
|
||||
console.log(`✅ Created (RED): ${test.file}`);
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Aggregate Fixture Needs
|
||||
|
||||
**Collect all fixture needs from both subprocesses:**
|
||||
|
||||
```javascript
|
||||
const allFixtureNeeds = [...apiTestsOutput.fixture_needs, ...e2eTestsOutput.fixture_needs];
|
||||
|
||||
// Remove duplicates
|
||||
const uniqueFixtures = [...new Set(allFixtureNeeds)];
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Generate Fixture Infrastructure
|
||||
|
||||
**Create fixtures needed by ATDD tests:**
|
||||
(Similar to automate workflow, but may be simpler for ATDD since feature not implemented)
|
||||
|
||||
**Minimal fixtures for TDD red phase:**
|
||||
|
||||
```typescript
|
||||
// tests/fixtures/test-data.ts
|
||||
export const testUserData = {
|
||||
email: 'test@example.com',
|
||||
password: 'SecurePass123!',
|
||||
};
|
||||
```
|
||||
|
||||
Note: More complete fixtures will be needed when moving to green phase.
|
||||
|
||||
---
|
||||
|
||||
### 6. Generate ATDD Checklist
|
||||
|
||||
**Create ATDD checklist document:**
|
||||
|
||||
```markdown
|
||||
# ATDD Checklist: [Story Name]
|
||||
|
||||
## TDD Red Phase (Current)
|
||||
|
||||
✅ Failing tests generated
|
||||
|
||||
- API Tests: {api_test_count} tests (all skipped)
|
||||
- E2E Tests: {e2e_test_count} tests (all skipped)
|
||||
|
||||
## Acceptance Criteria Coverage
|
||||
|
||||
{list all acceptance criteria with test coverage}
|
||||
|
||||
## Next Steps (TDD Green Phase)
|
||||
|
||||
After implementing the feature:
|
||||
|
||||
1. Remove `test.skip()` from all test files
|
||||
2. Run tests: `npm test`
|
||||
3. Verify tests PASS (green phase)
|
||||
4. If any tests fail:
|
||||
- Either fix implementation (feature bug)
|
||||
- Or fix test (test bug)
|
||||
5. Commit passing tests
|
||||
|
||||
## Implementation Guidance
|
||||
|
||||
Feature endpoints to implement:
|
||||
{list endpoints from API tests}
|
||||
|
||||
UI components to implement:
|
||||
{list UI flows from E2E tests}
|
||||
```
|
||||
|
||||
**Save checklist:**
|
||||
|
||||
```javascript
|
||||
fs.writeFileSync(`{test_artifacts}/atdd-checklist-{story-id}.md`, checklistContent, 'utf8');
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Calculate Summary Statistics
|
||||
|
||||
**Aggregate test counts:**
|
||||
|
||||
```javascript
|
||||
const summary = {
|
||||
tdd_phase: 'RED',
|
||||
total_tests: apiTestsOutput.test_count + e2eTestsOutput.test_count,
|
||||
api_tests: apiTestsOutput.test_count,
|
||||
e2e_tests: e2eTestsOutput.test_count,
|
||||
all_tests_skipped: true,
|
||||
expected_to_fail: true,
|
||||
fixtures_created: uniqueFixtures.length,
|
||||
acceptance_criteria_covered: [
|
||||
...apiTestsOutput.tests.flatMap((t) => t.acceptance_criteria_covered),
|
||||
...e2eTestsOutput.tests.flatMap((t) => t.acceptance_criteria_covered),
|
||||
],
|
||||
knowledge_fragments_used: [...apiTestsOutput.knowledge_fragments_used, ...e2eTestsOutput.knowledge_fragments_used],
|
||||
subprocess_execution: 'PARALLEL (API + E2E)',
|
||||
performance_gain: '~50% faster than sequential',
|
||||
};
|
||||
```
|
||||
|
||||
**Store summary for Step 5:**
|
||||
|
||||
```javascript
|
||||
fs.writeFileSync('/tmp/tea-atdd-summary-{{timestamp}}.json', JSON.stringify(summary, null, 2), 'utf8');
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## OUTPUT SUMMARY
|
||||
|
||||
Display to user:
|
||||
|
||||
```
|
||||
✅ ATDD Test Generation Complete (TDD RED PHASE)
|
||||
|
||||
🔴 TDD Red Phase: Failing Tests Generated
|
||||
|
||||
📊 Summary:
|
||||
- Total Tests: {total_tests} (all with test.skip())
|
||||
- API Tests: {api_tests} (RED)
|
||||
- E2E Tests: {e2e_tests} (RED)
|
||||
- Fixtures Created: {fixtures_created}
|
||||
- All tests will FAIL until feature implemented
|
||||
|
||||
✅ Acceptance Criteria Coverage:
|
||||
{list all covered criteria}
|
||||
|
||||
🚀 Performance: Parallel execution ~50% faster than sequential
|
||||
|
||||
📂 Generated Files:
|
||||
- tests/api/[feature].spec.ts (with test.skip())
|
||||
- tests/e2e/[feature].spec.ts (with test.skip())
|
||||
- tests/fixtures/test-data.ts
|
||||
- {test_artifacts}/atdd-checklist-{story-id}.md
|
||||
|
||||
📝 Next Steps:
|
||||
1. Implement the feature
|
||||
2. Remove test.skip() from tests
|
||||
3. Run tests → verify PASS (green phase)
|
||||
4. Commit passing tests
|
||||
|
||||
✅ Ready for validation (Step 5 - verify tests fail as expected)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## EXIT CONDITION
|
||||
|
||||
Proceed to Step 5 when:
|
||||
|
||||
- ✅ All test files written to disk (API + E2E)
|
||||
- ✅ All tests verified to have test.skip()
|
||||
- ✅ All fixtures created
|
||||
- ✅ ATDD checklist generated
|
||||
- ✅ Summary statistics calculated and saved
|
||||
- ✅ Output displayed to user
|
||||
|
||||
---
|
||||
|
||||
### 8. Save Progress
|
||||
|
||||
**Save this step's accumulated work to `{outputFile}`.**
|
||||
|
||||
- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-04c-aggregate']
|
||||
lastStep: 'step-04c-aggregate'
|
||||
lastSaved: '{date}'
|
||||
---
|
||||
```
|
||||
|
||||
Then write this step's output below the frontmatter.
|
||||
|
||||
- **If `{outputFile}` already exists**, update:
|
||||
- Add `'step-04c-aggregate'` to `stepsCompleted` array (only if not already present)
|
||||
- Set `lastStep: 'step-04c-aggregate'`
|
||||
- Set `lastSaved: '{date}'`
|
||||
- Append this step's output to the appropriate section.
|
||||
|
||||
Load next step: `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Both subprocesses succeeded
|
||||
- All tests have test.skip() (TDD red phase compliant)
|
||||
- All tests assert expected behavior (not placeholders)
|
||||
- All test files written to disk
|
||||
- ATDD checklist generated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- One or both subprocesses failed
|
||||
- Tests missing test.skip() (would break CI)
|
||||
- Tests have placeholder assertions
|
||||
- Test files not written to disk
|
||||
- ATDD checklist missing
|
||||
|
||||
**Master Rule:** TDD RED PHASE requires ALL tests to use test.skip() and assert expected behavior.
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: 'step-05-validate-and-complete'
|
||||
description: 'Validate ATDD outputs and summarize'
|
||||
outputFile: '{test_artifacts}/atdd-checklist-{story_id}.md'
|
||||
---
|
||||
|
||||
# Step 5: Validate & Complete
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate ATDD outputs and provide a completion summary.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- 📖 Read the entire step file before acting
|
||||
- ✅ Speak in `{communication_language}`
|
||||
- ✅ Validate against the checklist
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 Record outputs before proceeding
|
||||
- 📖 Load the next step only when instructed
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: config, loaded artifacts, and knowledge fragments
|
||||
- Focus: this step's goal only
|
||||
- Limits: do not execute future steps
|
||||
- Dependencies: prior steps' outputs (if any)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
## 1. Validation
|
||||
|
||||
Use `checklist.md` to validate:
|
||||
|
||||
- Prerequisites satisfied
|
||||
- Test files created correctly
|
||||
- Checklist matches acceptance criteria
|
||||
- Tests are designed to fail before implementation
|
||||
- [ ] CLI sessions cleaned up (no orphaned browsers)
|
||||
- [ ] Temp artifacts stored in `{test_artifacts}/` not random locations
|
||||
|
||||
Fix any gaps before completion.
|
||||
|
||||
---
|
||||
|
||||
## 2. Completion Summary
|
||||
|
||||
Report:
|
||||
|
||||
- Test files created
|
||||
- Checklist output path
|
||||
- Key risks or assumptions
|
||||
- Next recommended workflow (e.g., implementation or `automate`)
|
||||
|
||||
---
|
||||
|
||||
## 3. Save Progress
|
||||
|
||||
**Save this step's accumulated work to `{outputFile}`.**
|
||||
|
||||
- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-05-validate-and-complete']
|
||||
lastStep: 'step-05-validate-and-complete'
|
||||
lastSaved: '{date}'
|
||||
---
|
||||
```
|
||||
|
||||
Then write this step's output below the frontmatter.
|
||||
|
||||
- **If `{outputFile}` already exists**, update:
|
||||
- Add `'step-05-validate-and-complete'` to `stepsCompleted` array (only if not already present)
|
||||
- Set `lastStep: 'step-05-validate-and-complete'`
|
||||
- Set `lastSaved: '{date}'`
|
||||
- Append this step's output to the appropriate section.
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Step completed in full with required outputs
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipped sequence steps or missing outputs
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
Reference in new issue
Block a user