qa-test-review

Adversarial reviewer specialized for assertion quality - flags weak / vague matchers (`expect(x).toBeTruthy()` / `.toBeDefined()` / `.toContain('error')` style) and recommends specific replacements (`.toEqual({...})` / `.toBe(expected)` / `.toMatch(regex)`). Walks per-§4 of `test-code-conventions`. Use during PR review against test files; complements `test-code-critic` (which handles structure / naming) and `mocking-anti-pattern-detector` (which handles mocking specificity).

Adversarial reviewer specialized for E2E test selectors - flags brittle CSS class selectors / nth-child / XPath / position-based selectors and recommends `getByRole` / `getByLabelText` / accessibility-first equivalents per Testing Library''''s priority order. Also flags non-web-first assertions (`.isVisible()` checked synchronously vs `await expect(...).toBeVisible()`). Per Playwright best practices: "automated tests should verify that the application code works for the end users, and avoid relying on implementation details." Use against any E2E test files (Playwright / Cypress / Selenium / WebdriverIO).

Adversarial reviewer that audits the test framework codebase at the **architecture tier** - POM consistency across pages, base-class hierarchy depth, fixture coupling and scope, helper sprawl, naming-convention drift between modules, retry / wait convention consistency, documented-vs-actual convention drift, CI integration health, and dead helpers. Operates on the whole test directory, not individual test files. Distinct from `test-code-critic`, `assertion-quality-reviewer`, `e2e-selector-quality-critic`, and `mocking-anti-pattern-detector` (sibling critics in this plugin, each reviewing individual test files); this agent reviews **patterns across files** that per-file critics structurally cannot see. Use as a quarterly / per-release framework-health audit, or before a major refactor.

Adversarial reviewer specialized for mocking patterns - flags over-mocking (mocking what the team owns when state verification would do), mock chains (`when(a.method()).thenReturn(when(b.x).thenReturn(...))` style coupling), behavior-verification leakage (asserting which methods were called instead of asserting on the SUT''''s resulting state), and mocking what the team doesn''''t own (third-party libraries / framework internals). Per Fowler''''s classical (Detroit) school: prefer state verification; fakes over mocks for stateful collaborators. Use during PR review against test files.

Adversarial reviewer specialized for **test files only** - flags violations of the conventions in `test-code-conventions` (AAA structure, single-responsibility per test, descriptive naming, magic numbers, slow setup) with file:line evidence and the convention-section reference. Refuses to review non-test files (production code is the job of saturated production-reviewer agents elsewhere). Use as a PR-time check that runs only against `*.spec.*` / `*.test.*` / `tests/**` paths.

Pure reference catalog of the canonical object-model architecture patterns for test automation frameworks - Page Object Model (Fowler), Screenplay (Marcano/Palmer/Hill), Component Object, App Actions (Cypress idiom), Service Object, Repository, and Screen Object (the desktop/mobile sibling of Page Object covering Windows UIA, macOS XCTest, Linux AT-SPI, Appium / Espresso) - each with its canonical citation, when-to-use rules, refuse-to-mix anti-patterns, and a worked example. Distinct from `test-code-conventions` (file-level §1-§10) and from per-framework skills (`playwright-testing` etc., tool-specific configuration). Preloaded by `framework-architecture-auditor` and `playwright-codegen-reviewer` as the architecture-tier reference for what each pattern actually is.

Pure-reference catalog of test code conventions - AAA structure (Arrange / Act / Assert), per-test single-responsibility, descriptive naming patterns (`<system_under_test>_<scenario>_<expected>` vs nested describe), assertion specificity, fixture-coupling rules, and the magic-number / hard-coded-string anti-pattern. The agents in this plugin (test-code-critic, assertion-quality-reviewer, mocking-anti-pattern-detector, e2e-selector-quality-critic) load this as their shared rule book. Use as a team's onboarding reference for "what makes a test code-reviewable" and as the source-of-truth the critics' verdicts cite back to.

Pure reference catalog of test-isolation and fixture-lifecycle patterns - fixture scope (per-test / per-describe / shared / global), Meszaros's four-phase test pattern, Fowler's Fresh-Fixture-vs-Shared-Fixture trade-off, database isolation (transaction-rollback / database-per-worker / template-database), parallel-safety patterns, and cleanup discipline (afterEach / afterAll / tagged-cleanup). Distinct from `test-code-conventions` §6 (file-level fixture coupling rule) - this catalog is the architecture-tier reference. Preloaded by `framework-architecture-auditor` to anchor the §A3 fixture-coupling and §A6 retry/wait audits.

Pure reference catalog of test-step design patterns at the architecture tier - step granularity (one logical action per step), abstraction layers (mechanical → page → business), step extraction rules (when to inline / when to extract to a helper / when to extract to a Page Object method), the declarative-vs-imperative phrasing rule, FIRST principles (Fast / Independent / Repeatable / Self-validating / Timely), and the AAA / Given-When-Then mapping. Distinct from `test-code-conventions` §1 (AAA structure at the file level) and from `manual-step-to-gherkin` (Gherkin-specific translation) - this catalog is the cross-framework architecture-tier reference for what a step IS, when it should exist, and where it should live.