Add test coverage checklist, report template, and stack matrix for ecommerce project

- Created a test coverage checklist to ensure comprehensive testing of backend and frontend components.
- Added a test report template to standardize reporting on test execution results and gaps.
- Introduced a test stack matrix to guide the selection of testing tools and frameworks for backend and frontend.
- Established a skill for repairing failing tests, including a failure triage checklist and a test repair template.
- Documented recommended MCP stack for ecommerce development with FastAPI and React/Next.js.
- Developed a detailed README outlining the project structure, agent capabilities, and recommended workflows.
- Compiled a comprehensive workflow guide detailing step-by-step commands for project setup, testing, and SEO implementation.
This commit is contained in:
ВяткинАртём
2026-05-20 18:09:24 +03:00
parent 5699670ea0
commit 2817cf8dc6
96 changed files with 2987 additions and 2888 deletions
@@ -0,0 +1,47 @@
---
name: ecommerce-test-implementation
description: 'Write automated tests for backend and frontend, then run them. Use for creating or extending pytest, frontend unit, integration, and UI tests in an ecommerce project and producing a test execution report.'
argument-hint: 'Describe whether to cover the whole project or focus on backend, frontend, checkout, auth, catalog, admin, or other flows'
---
# Ecommerce Test Implementation
## When to use
- After building a new ecommerce project.
- After adding or changing backend or frontend features.
- When the project lacks automated tests for important commerce flows.
## Goal
- Add meaningful automated tests for backend and frontend.
- Run the relevant test suites.
- Produce or update .ai/TEST-REPORT.md with coverage notes, executed commands, and failures.
## Required workflow
1. Read project configuration first: `pyproject.toml`, `package.json`, and existing test config files.
2. Detect the current test stack using [test stack matrix](./assets/test-stack-matrix.md).
3. Identify the highest-risk flows using [test coverage checklist](./assets/test-coverage-checklist.md).
4. Before serious backend or frontend edits, create a timestamped snapshot under .backup/ and leave older backup entries untouched.
5. Add or update tests in the project's existing style where possible.
6. If the project has no coherent test baseline, create a minimal sensible baseline rather than skipping tests.
7. Run the relevant backend and frontend tests.
8. Record results in .ai/TEST-REPORT.md using [test report template](./assets/test-report-template.md).
9. If tests fail, stop pretending everything is fine and recommend running the test-repair workflow.
## What to cover by default
- Backend: API contracts, auth, permissions, catalog, cart, orders, admin endpoints, validation, and regression-prone business logic.
- Frontend: page rendering, key user flows, empty/loading/error states, and critical UI interactions.
- If the project already has UI or end-to-end tooling, cover the most important high-value flows with it.
## Constraints
- Do not add shallow tests that only restate implementation with no confidence gain.
- Prefer high-signal tests over bloated low-value suites.
- Respect the existing framework and test runner unless it is clearly absent or broken.
## Outputs
- Test code in the project.
- .ai/TEST-REPORT.md.
- Clear next step when failures exist: run the test-repair workflow.
## References
- [test stack matrix](./assets/test-stack-matrix.md)
- [test coverage checklist](./assets/test-coverage-checklist.md)
- [test report template](./assets/test-report-template.md)
@@ -0,0 +1,27 @@
# Test Coverage Checklist
## Backend
- Auth and permission rules.
- Catalog reads and writes.
- Cart behavior.
- Order creation and lifecycle.
- Admin operations.
- Input validation and error responses.
- Critical business logic and edge cases.
## Frontend
- Key page rendering.
- Empty, loading, and error states.
- User interactions for catalog, cart, checkout, auth, and account.
- Admin UI interactions when the repo contains admin code.
## High-priority ecommerce flows
- Add to cart.
- Quantity updates and cart totals.
- Checkout or lead flow.
- Login and protected routes.
- Admin create or edit flows.
## Review quality
- Assertions should verify behavior, not just implementation details.
- Avoid fragile snapshot-heavy suites unless they truly add confidence.
@@ -0,0 +1,24 @@
# TEST-REPORT.md Template
## 1. Scope
- Areas covered
- Test frameworks used
- Commands executed
## 2. Added or Updated Tests
- Backend tests
- Frontend tests
- UI or end-to-end tests if any
## 3. Execution Results
- Passing suites
- Failing suites
- Skipped or unrun suites
## 4. Gaps
- Areas still missing coverage
- Risky flows still not tested
## 5. Next Step
- If failures exist, run the test-repair workflow.
- If green, note whether more coverage is still recommended.
@@ -0,0 +1,20 @@
# Test Stack Matrix
## Backend
- Prefer the existing Python test runner and fixtures setup.
- If the project is FastAPI and already uses `pytest`, extend `pytest` rather than introducing another runner.
- Respect async testing patterns already present in the project.
## Frontend
- Prefer the existing frontend test stack from `package.json`.
- Typical unit and integration options: Vitest or Jest with Testing Library.
- Typical UI or end-to-end options: Playwright when the project already uses it or clearly benefits from it.
## If the project has no test stack
- Backend default: `pytest`.
- Frontend default for React and Next.js component testing: Vitest plus Testing Library when compatible with the project.
- End-to-end tests should be added only if they materially improve coverage and the project can support them.
## Execution principle
- Run only the relevant suites for the change set when that is enough.
- If the task is broad, run both backend and frontend suites or document what was not run.