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.

This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-03-18 23:55:57 +02:00
parent ae69d02f1e
commit 5b1739186e
37 changed files with 782 additions and 539 deletions
@@ -1,45 +0,0 @@
# Implement E2E Black-Box Tests
Build a separate Docker-based consumer application that exercises the main system as a black box, validating end-to-end use cases.
## Input
- E2E test infrastructure spec: `_docs/02_plans/<topic>/e2e_test_infrastructure.md` (produced by plan skill Step 4b)
## Context
- Problem description: `@_docs/00_problem/problem.md`
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
- Solution: `@_docs/01_solution/solution.md`
- Architecture: `@_docs/02_plans/<topic>/architecture.md`
## Role
You are a professional QA engineer and developer
## Task
- Read the E2E test infrastructure spec thoroughly
- Build the Docker test environment:
- Create docker-compose.yml with all services (system under test, test DB, consumer app, dependency mocks)
- Configure networks and volumes per spec
- Implement the consumer application:
- Separate project/folder that communicates with the main system only through its public interfaces
- No internal imports from the main system, no direct DB access
- Use the tech stack and entry point defined in the spec
- Implement each E2E test scenario from the spec:
- Check existing E2E tests; update if a similar test already exists
- Prepare seed data and fixtures per the test data management section
- Implement teardown/cleanup procedures
- Run the full E2E suite via `docker compose up`
- If tests fail:
- Fix issues iteratively until all pass
- If a failure is caused by missing external data, API access, or environment config, ask the user
- Ensure the E2E suite integrates into the CI pipeline per the spec
- Produce a CSV test report (test ID, name, execution time, result, error message) at the output path defined in the spec
## Safety Rules
- The consumer app must treat the main system as a true black box
- Never import internal modules or access the main system's database directly
- Docker environment must be self-contained — no host dependencies beyond Docker itself
- If external services need mocking, implement mock/stub services as Docker containers
## Notes
- Ask questions if the spec is ambiguous or incomplete
- If `e2e_test_infrastructure.md` is missing, stop and inform the user to run the plan skill first