Update README to reflect changes in test infrastructure organization and task decomposition workflow. Remove obsolete E2E test templates and clarify input specifications for integration tests. Enhance documentation for planning and implementation phases, including new directory structures and task management processes.

2026-04-23 03:26:38 +00:00 · 2026-03-18 23:55:57 +02:00
parent ae69d02f1e
commit 5b1739186e
37 changed files with 782 additions and 539 deletions
@@ -0,0 +1,78 @@
+# E2E Functional Tests Template
+
+Save as `PLANS_DIR/integration_tests/functional_tests.md`.
+
+---
+
+```markdown
+# E2E Functional Tests
+
+## Positive Scenarios
+
+### FT-P-01: [Scenario Name]
+
+**Summary**: [One sentence: what end-to-end use case this validates]
+**Traces to**: AC-[ID], AC-[ID]
+**Category**: [which AC category — e.g., Position Accuracy, Image Processing, etc.]
+
+**Preconditions**:
+- [System state required before test]
+
+**Input data**: [reference to specific data set or file from test_data.md]
+
+**Steps**:
+
+| Step | Consumer Action | Expected System Response |
+|------|----------------|------------------------|
+| 1 | [call / send / provide input] | [response / event / output] |
+| 2 | [call / send / provide input] | [response / event / output] |
+
+**Expected outcome**: [specific, measurable result]
+**Max execution time**: [e.g., 10s]
+
+---
+
+### FT-P-02: [Scenario Name]
+
+(repeat structure)
+
+---
+
+## Negative Scenarios
+
+### FT-N-01: [Scenario Name]
+
+**Summary**: [One sentence: what invalid/edge input this tests]
+**Traces to**: AC-[ID] (negative case), RESTRICT-[ID]
+**Category**: [which AC/restriction category]
+
+**Preconditions**:
+- [System state required before test]
+
+**Input data**: [reference to specific invalid data or edge case]
+
+**Steps**:
+
+| Step | Consumer Action | Expected System Response |
+|------|----------------|------------------------|
+| 1 | [provide invalid input / trigger edge case] | [error response / graceful degradation / fallback behavior] |
+
+**Expected outcome**: [system rejects gracefully / falls back to X / returns error Y]
+**Max execution time**: [e.g., 5s]
+
+---
+
+### FT-N-02: [Scenario Name]
+
+(repeat structure)
+```
+
+---
+
+## Guidance Notes
+
+- Functional tests should typically trace to at least one acceptance criterion or restriction. Tests without a trace are allowed but should have a clear justification.
+- Positive scenarios validate the system does what it should.
+- Negative scenarios validate the system rejects or handles gracefully what it shouldn't accept.
+- Expected outcomes must be specific and measurable — not "works correctly" but "returns position within 50m of ground truth."
+- Input data references should point to specific entries in test_data.md.