Should I test that?
One decision per testing question: yes, no, or the conditions under which a test pays off. Every answer follows one published framework.
Decide for your case
Result
Answer all five questions to see the decision. 0 of 5 answered.
Nothing you enter here leaves your browser. The tool runs the published rules locally and makes no network requests.
Questions by area
- Code
Which parts of your own code deserve a test: private methods, getters, logging, migrations and other small pieces.
- AI and LLM products
How to test products built on models: prompts, LLM outputs, retrieval, agents and model upgrades.
- Product decisions
Whether prototypes, MVPs, internal tools, experiments and code under deadline need tests at all.
- Test depth
How far to go: coverage targets, E2E for every page, regression tests, snapshots and mutation testing.
- External boundaries
What to test where your code meets third-party APIs, ORMs, queues, payments, email and webhooks.
- Interface
What to test in the interface: CSS, layouts, animations, accessibility, visual regression and copy.
- Data and state
How to test data and state: production data, migrations, caching, race conditions, dates and time zones.
- Regulated environments
What to test when the law is involved: audit logs, health data, consent, retention, access control and encryption.
- Security
Which security behaviours need their own tests: injection, XSS, auth, rate limits, sessions and dependencies.
- Infrastructure and CI
Whether to test infrastructure code, Dockerfiles, pipelines, deployment scripts, health checks and alerts.
- Mobile
What to test in mobile apps: real devices, OS versions, offline mode, push notifications and deep links.
- Practices
Testing practices under question: tests first, testing in production, manual testing, flaky tests and types.