Every test file contains at least one assertion
Why it matters
An assertion-free test file is indistinguishable from a passing test in CI — it runs, it exits 0, and it tells you nothing. AI-generated test suites routinely produce these: scaffolded describe/it blocks that call setup helpers but never verify a return value, a side effect, or a thrown error. The gap only surfaces when a real defect slips to production and you realize your test suite was never checking anything. ISO-25010:2011 testability requires that tests can actually detect faults; assertion-free files by definition cannot.
Severity rationale
Critical because a test that cannot fail provides zero defect-detection value regardless of how many times it runs.
Remediation
Add at least one assertion to every it/test block. Every call to createUser, fetchOrder, or any production function should be followed by an expect on its return value or side effect. Replace empty or setup-only test bodies with real verifications:
// Before: passes when createUser is completely broken
it('creates a user', async () => {
await createUser({ email: 'test@example.com' })
})
// After: fails if id, email, or timestamp is wrong
it('creates a user', async () => {
const user = await createUser({ email: 'test@example.com' })
expect(user.id).toBeDefined()
expect(user.email).toBe('test@example.com')
expect(user.createdAt).toBeInstanceOf(Date)
})
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Test Reality Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.testability — Testability (maintainability sub-characteristic)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ai-slop-test-theater·automated