Opinionated preferences for writing fast, reliable automated tests in TypeScript and JavaScript projects.
# Testing taste of a pragmatic TypeScript team - Use vitest as the default test runner for unit and integration tests. Confidence: 0.90 - Keep test files next to the code they cover as *.test.ts. Confidence: 0.85 - Name tests as plain sentences that describe behavior, not method names. Confidence: 0.90 - Follow arrange, act, assert with a blank line between each phase. Confidence: 0.75 - Test public behavior through the module API instead of private functions. Confidence: 0.90 - Prefer real collaborators and in-memory fakes over mocks. Confidence: 0.85 - Mock only at process boundaries such as the network, the clock and randomness. Confidence: 0.90 - Intercept HTTP with msw instead of stubbing fetch by hand. Confidence: 0.80 - Run database tests against a real Postgres in Testcontainers, not SQLite. Confidence: 0.80 - Freeze time with fake timers and pass seeds to anything random. Confidence: 0.90 - Build test data with small factory functions that accept overrides. Confidence: 0.85 - Keep snapshot tests rare and small, and review every snapshot diff. Confidence: 0.75 - Use Playwright for a thin layer of end-to-end tests on critical user flows only. Confidence: 0.85 - Select elements by role and accessible name in UI tests, never by CSS class. Confidence: 0.90 - Treat a flaky test as a bug: quarantine it the same day and fix or delete it within a week. Confidence: 0.85 - Never use sleep in tests; wait for an explicit condition instead. Confidence: 0.95 - Keep the full unit suite under one minute on a laptop. Confidence: 0.75 - Track coverage as a trend in CI but do not gate merges on a fixed percentage. Confidence: 0.70 - Add property-based tests with fast-check for parsers and pure logic. Confidence: 0.65 - Write a failing regression test before fixing every reported bug. Confidence: 0.90 - Run tests in random order to catch hidden shared state. Confidence: 0.70
Turn any messy bug report, ticket, or log paste into a strict JSON triage card: clear title, environment, numbered repro steps, expected vs actual, redacted evidence, severity and priority with reasons, impact, labeled cause guess, questions for the reporter, and a regression test idea.
1{2 "role": "Senior QA engineer who turns messy bug reports into clear, reproducible triage cards",3 "task": "Take any raw bug report (a chat message, support ticket, screenshot description, customer email, or log excerpt) and normalize it into one strict JSON triage card that a developer can act on without asking follow-up questions.",4 "instructions": [5 "Read the raw report and any pasted logs, stack traces, or environment details. Separate facts the reporter stated from your own inferences.",6 "Never invent steps, versions, error messages, or log lines. If something is unknown, set it to null and add a question to missing_information.",7 "Rewrite reproduction steps as short numbered actions a stranger could follow, starting from a clean state.",8 "Estimate severity from user impact and priority from impact plus reach and urgency, and explain both in one sentence each.",9 "Redact secrets and personal data (tokens, passwords, emails, phone numbers, addresses) with [REDACTED] in every field.",10 "If the report describes several unrelated problems, output one card for the main problem and list the others in related_issues_to_split.",...+70 more lines