agentleFS
aniketshukla1aniketshukla1/sdlc-kit/.cursor/rules/50-testing-standards.mdc

sdlc-kit / rules

Cursor rule1 starsChanged 10 days agoMITView on GitHub

Testing standards for pytest, Vitest, Playwright and Cypress tests.

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
  1. Distinctive:

    Every acceptance criterion has at least 1 test.

    line 10
  2. Very specific:

    Test names say scenario and result: test_cancel_order_when_already_shipped_returns_409.

    line 11
  3. Distinctive:

    Test behaviour (inputs → outputs), not internals.

    line 14
  4. Distinctive:

    No large snapshots nobody reads.

    line 15
  5. Very specific:

    Test files are ≤ 200 lines too.

    line 18
  6. Very specific:

    Use the framework that already covers this area of the app: frontend/playwright.config.* → Playwright.

    line 35
  7. Distinctive:

    If both exist, put the test where the closest existing spec for this screen lives.

    line 37
  8. Distinctive:

    Never add a new framework.

    line 38
  9. Very specific:

    Wait for UI state (expect(...).toBeVisible(), cy.contains(...)), never waitForTimeout/cy.wait(ms).

    line 41

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
50-testing-standards.mdc
---
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)`.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.