qcheckt

QCHECKT - Test-Focused Review

When user types "qcheckt", execute this workflow as a SKEPTICAL senior software engineer:

Focus: Writing Tests Best Practices Only

For every MAJOR test added or edited (skip minor changes):

Test Quality Checklist (CLAUDE.md)

1. Parameterized Inputs: SHOULD parameterize inputs; never embed unexplained literals such as 42 or "foo" directly in test
2. Real Defect Testing: SHOULD NOT add test unless it can fail for real defect. Trivial asserts (e.g., expect(2).toBe(2)) are forbidden
3. Description Alignment: SHOULD ensure test description states exactly what the final expect verifies. If wording and assert don't align, rename or rewrite
4. Independent Expectations: SHOULD compare results to independent, pre-computed expectations or domain properties, never to function's output re-used as oracle
5. Code Standards: SHOULD follow same lint, type-safety, and style rules as prod code (prettier, ESLint, strict types)
6. Property Testing: SHOULD express invariants or axioms (commutativity, idempotence, round-trip) rather than single hard-coded cases when practical. Use fast-check library
7. Test Grouping: Unit tests for function should be grouped under describe(functionName, () => ...
8. Parameter Testing: Use expect.any(...) when testing for parameters that can be anything (e.g. variable ids)
9. Strong Assertions: ALWAYS use strong assertions over weaker ones e.g. expect(x).toEqual(1) instead of expect(x).toBeGreaterThanOrEqual(1)
10. Edge Cases: SHOULD test edge cases, realistic input, unexpected input, and value boundaries
11. Type Safety: SHOULD NOT test conditions that are caught by the type checker

Response Template

🧪 **QCHECKT - Test Review**

**Tests Analyzed:**

**Test**: `testName` in `file.test.ts`
1. **Parameterized**: ✅/❌ [No magic literals like 42, "foo"?]
2. **Real Defects**: ✅/❌ [Can fail for actual bugs, not trivial?]
3. **Description**: ✅/❌ [Description matches what expect verifies?]
4. **Independent**: ✅/❌ [Expectations independent of implementation?]
5. **Standards**: ✅/❌ [Follows lint/type/style rules?]
6. **Properties**: ✅/❌ [Uses invariants/axioms when possible?]
7. **Grouping**: ✅/❌ [Grouped under describe(functionName)?]
8. **Parameters**: ✅/❌ [Uses expect.any() appropriately?]
9. **Strong Asserts**: ✅/❌ [Strong over weak assertions?]
10. **Edge Cases**: ✅/❌ [Covers boundaries/unexpected input?]
11. **Type Safety**: ✅/❌ [Doesn't test type-checker conditions?]

**Property Testing Opportunities:**
[Could this test benefit from fast-check invariants?]

**Edge Cases Coverage:**
- Boundaries: ✅/❌
- Empty/null inputs: ✅/❌  
- Invalid inputs: ✅/❌
- Large datasets: ✅/❌

**Recommendations:**
[Specific suggestions for test improvement]

**Test Status:** ✅ Solid / ⚠️ Needs improvement / ❌ Rewrite needed