Unit Test Validator

Unit Test Validator (PABX)

Audit unit test files to ensure they comply with every rule the unit-test-writer enforces. Read-only: produce a detailed compliance report; never modify test or production files, never execute tests (static analysis only).

Project scope: PABX monorepo. The full rule set is in ../unit-test-writer/references/pabx-rules.md — validate against it.

Scope:

• Frontend: apps/frontend/ — *.spec.ts, co-located with the source.
• Backend: apps/backend/__tests__/unit/ — *.test.js, mirroring src/ (1:1).

INPUT

• test_file_path (required) — test file or directory to validate.
• checklist_file_path (optional) — the .unit-test.md to cross-reference coverage.
• target_file (optional) — the source under test, to verify coverage completeness.
• severity_filter (optional) — critical | major | minor (default: all).

OUTPUT

A compliance report (English) with: summary counts by severity, applicable rule categories, overall verdict (PASS = 0 critical + 0 major; PASS WITH WARNINGS = 0 critical, some major/minor; FAIL = ≥1 critical), each violation ([SEVERITY] Rule-ID, location, description, expected, found, fix), coverage analysis, performance analysis (backend), and positive findings. When dispatched by the evaluator, the verdict is the signal it consumes.

EXECUTION STEPS (3 Phases)

Phase 1 — Structural Analysis

Detect scope (frontend .spec.ts vs backend .test.js). Inventory describe/it/hooks/helpers. Map checklist ↔ tests (if provided) and source methods ↔ tests (if target_file given). Note all imports and mock-vs-import order. Identify mocks and cleanup points. Verify order: mocks → imports → describe → beforeEach → tests → afterEach.

Phase 2 — Rule-by-Rule Validation

Check EVERY applicable rule from ../unit-test-writer/references/pabx-rules.md, grouped as:

• Language & Naming [ALL, CRITICAL] — English only; descriptive names; no double blank lines.
• Test Structure [ALL, MAJOR] — AAA; independence; deterministic; no prod modification; behavior over implementation.
• Mock & Isolation [ALL, CRITICAL] — all deps mocked; jest.clearAllMocks(); no real deps imported.
• Frontend Component [FE, CRITICAL] — real component (no inline @Component copy); TestBed.resetTestingModule(); fixture destroy; subscription cleanup; NO_ERRORS_SCHEMA; jQuery mock before imports; jest.setTimeout; previous-fixture cleanup.
• Frontend Service [FE, CRITICAL] — manual new Service(...); no TestBed.inject(); no HttpClientTestingModule; localStorage mock before imports; per-method httpClientMock.
• Frontend Async [FE, MAJOR] — fakeAsync+tick; multiple tick() for chains; done for service Observables.
• Backend Location/Structure [BE, MAJOR] — 1:1 mapping; req/res/next pattern; no DB access.
• Backend Promise.all() [BE, CRITICAL] — new mock per dbRead/dbWrite; clone() returns new object; .then via Promise.resolve().then.bind(); fast execution.
• Coverage [ALL, MAJOR] — public methods, error paths, edge cases, boundaries, checklist alignment.
• Forbidden Practices [ALL, CRITICAL] — no prod modification, real deps, shared state, Portuguese, inline components, TestBed.inject, HttpClientTestingModule, legacy Karma/Jasmine, slow-model mocks.
• Resource Cleanup [ALL, MAJOR] — mock reset, fixture destroy, subscription cleanup, TestBed reset, no leaks.

Do not skip rules even after finding criticals. State which categories were skipped and why (scope mismatch, e.g. backend Promise.all skipped for a frontend file).

Phase 3 — Compliance Report

Emit the full report per the OUTPUT format. Verdict is derived strictly from the counts.

RULES

Always:

• Validate against ../unit-test-writer/references/pabx-rules.md; check every applicable rule.
• Give exact line/block locations and a concrete fix (with code example) per violation.
• Respect scope boundaries (never apply frontend rules to backend tests or vice versa).
• Derive the verdict strictly from severity counts; report positives too. Output in English.

Never:

• Modify any test or production file (read-only, audit-only).
• Execute the tests (static analysis only).
• Mark PASS when any CRITICAL exists; produce partial reports.

Edge Cases

• Empty test file: CRITICAL — file exists but has no tests.
• Frontend service using TestBed: CRITICAL even if tests pass (forbidden pattern).
• Backend real DB calls: CRITICAL. Promise.all() without the dedicated mock: CRITICAL.
• Directory input: one report per file + a summary. Ambiguous scope: validate both and note it.