No tautological assertions
Why it matters
Tautological assertions — expect(true).toBe(true), assert(true), expect(1).toBe(1) — are placeholders that AI scaffolding generates and never replaces. They pass unconditionally, so a completely broken implementation looks identical to a working one in your test output. Teams relying on green CI as a signal of correctness are flying blind: the assertion validates the literal true you typed, not the behavior of your code. ISO-25010:2011 testability requires assertions that can actually fail when the system under test is defective.
Severity rationale
Critical because a tautology assertion passes regardless of what the production code does, making the test meaningless as a fault detector.
Remediation
Search for expect(true).toBe(true), assert(true), and expect(1).toBe(1) across all test files and replace each with an assertion against a real value returned or produced by the code under test. Delete the test entirely if the behavior isn't yet defined — a missing test is less dangerous than a permanently-passing fake one:
// Before: always passes
it('handles edge case', () => {
expect(true).toBe(true)
})
// After: fails if the production code returns the wrong shape
it('handles empty input', () => {
expect(parseInput('')).toEqual({ error: 'empty', input: '' })
})
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