sdlc-kit / rules
Cursor rule1 starsChanged 10 days agoMITView on GitHub
Testing standards for pytest, Vitest, Playwright and Cypress tests.
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 4,183 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/00-ticket-workflow.mdcCursor rule
- .cursor/rules/10-general-standards.mdcCursor rule
- .cursor/rules/20-backend-standards.mdcCursor rule
- .cursor/rules/30-frontend-standards.mdcCursor rule
- .cursor/rules/40-database-standards.mdcCursor rule
- backend-implementSkill
- chatSkill
- codebase-exploreSkill
- db-migrationSkill
- frontend-implementSkill
- gitlab-mrSkill
- implementation-planSkill
- jira-createSkill
- mr-feedbackSkill
- mr-reviewSkill
- quick-fixSkill
- run-checksSkill
- self-reviewSkill
- ticket-intakeSkill
- ticket-qaSkill
- write-testsSkill
The file
We split this 50-testing-standards.mdc into the rules it gives an agent
9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Every acceptance criterion has at least 1 test.
- Very specific: line 11
Test names say scenario and result: test_cancel_order_when_already_shipped_returns_409.
- Distinctive: line 14
Test behaviour (inputs → outputs), not internals.
- Distinctive: line 15
No large snapshots nobody reads.
- Very specific: line 18
Test files are ≤ 200 lines too.
- Very specific: line 35
Use the framework that already covers this area of the app: frontend/playwright.config.* → Playwright.
- Distinctive: line 37
If both exist, put the test where the closest existing spec for this screen lives.
- Distinctive: line 38
Never add a new framework.
- Very specific: line 41
Wait for UI state (expect(...).toBeVisible(), cy.contains(...)), never waitForTimeout/cy.wait(ms).
≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
---
description: Testing standards for pytest, Vitest, Playwright and Cypress tests.
globs: backend/tests/**,frontend/**/*.test.ts,frontend/**/*.test.tsx,frontend/e2e/**,frontend/cypress/**
paths: backend/tests/**,frontend/**/*.test.ts,frontend/**/*.test.tsx,frontend/e2e/**,frontend/cypress/**
alwaysApply: false
---
# Testing standards
## General
- Every acceptance criterion has at least 1 test. Every edge case in PLAN.md has a test or an "N/A: reason".
- Test names say scenario and result: `test_cancel_order_when_already_shipped_returns_409`.
- Arrange / Act / Assert, separated by a blank line. One behavior per test.
- Deterministic: no real network, no real current time (freeze it), no unseeded randomness, no fixed sleeps.
- Test behaviour (inputs → outputs), not internals. Mock only at boundaries (network, clock, slow services).
No large snapshots nobody reads.
- Assert exact values (status code, fields, message, visible text); never only "not None" or truthy.
- Code behind a feature flag: test it with the flag on and off.
- Test files are ≤ 200 lines too. Split by behavior (`test_orders_create.py`, `test_orders_cancel.py`).
- Reuse fixtures/factories from `conftest.py` and test utils. Don't copy-paste setup.
## Backend (pytest)
- `backend/tests/unit/<feature>/`: services, with repositories mocked.
- `backend/tests/integration/<feature>/`: routes through the test client with the test database.
- Minimum per endpoint: happy path, 422 invalid input, 404 not found, 401/403 auth,
409 duplicate (if a unique rule exists), pagination limits (if a list).
## Frontend (Vitest + React Testing Library)
- Query by role/label/text (`getByRole('button', { name: /save/i })`). Not by class names.
- Cover: renders data, loading, empty, error, validation messages, successful submit.
- Mock network the way existing tests do (MSW if present, else mock the api hooks).
- Type mock API data with the generated API types (`components["schemas"]["<Name>"]`) when `src/api/schema.d.ts`
exists, so a backend change breaks the mock at compile time.
## E2E (Playwright or Cypress)
- Use the framework that already covers this area of the app:
`frontend/playwright.config.*` → Playwright; `frontend/cypress.config.*` → Cypress.
If both exist, put the test where the closest existing spec for this screen lives.
- Never add a new framework. Never write the same flow in both.
- One spec per user-facing acceptance criterion: happy path + the most important failure.
- Select by role/label; `data-testid` only if no accessible selector exists.
- Wait for UI state (`expect(...).toBeVisible()`, `cy.contains(...)`), never `waitForTimeout`/`cy.wait(ms)`.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

