Testing Best Practices

Use this when you need to design or write tests and want opinionated structure instead of ad hoc chaos. It pushes you toward layered coverage: data-driven unit tests with property-based fuzzing, integration tests for contracts and auth boundaries, and state-tolerant e2e flows that run idempotently without assuming a clean slate. The hard rules are genuinely useful: no invented signatures, no fabricated fixtures, no test-only backdoors in product code. It produces test strategy, a matrix with case IDs, and an implementation plan. Best for teams that want testing discipline baked into the workflow rather than debated every sprint.