fxa-test-repair

name	fxa-test-repair
description	Reviews a test file for violations of FXA testing guidelines, then suggests concrete repairs. Does not auto-apply changes — output is a repair plan for engineer review.
allowed-tools	Bash, Read, Grep, Glob
argument-hint	<test-file-path>
user-invocable	true
context	fork

FXA Test Repair

Review a test file for violations of the FXA testing guidelines and produce a prioritized repair plan with before/after code suggestions. This skill does not modify files — all repairs are presented for engineer review for correctness and scope before implementation.

If scope of changes is large, suggest a reasonable subset of repairs to implement in a single pass to avoid overwhelming diffs and code review. Always prioritize correctness and test value over style — if a repair improves readability but risks changing test behavior, flag it as Medium severity and note the risk.

Read the testing rules before proceeding: .claude/rules/testing/base.md (general FXA test rules). The rule also auto-loads when Claude reads the target test file, but reading it explicitly here ensures the audit covers every rule even before the file is opened.

If the target file is a React component test (*.test.tsx), also read .claude/rules/testing/react.md and audit against those component-test rules in addition.

---

Step 1: Identify the Target File

If $ARGUMENTS is provided, use it as the test file path.

Otherwise check for recently changed test files:

git diff HEAD --name-only | grep -E '\.(spec|test)\.(ts|tsx)$'
git diff --cached --name-only | grep -E '\.(spec|test)\.(ts|tsx)$'

If multiple files are found, ask the engineer which to repair. If none, ask explicitly.

---

Step 2: Read the File

Read the full test file. Note:

• Total number of tests
• Testing framework (Jest vs Mocha — flag Mocha, no new tests should be added)
• How mocks are structured (module-level, beforeEach, inline)
• Whether shared state variables exist at module or describe scope

---

Step 3: Audit for Violations

Work through every rule in the shared guidelines. For each violation found, record: location, the rule it breaks, and a before/after repair snippet. If a rule has no violations, note it as clean — do not skip rules.

---

Step 4: Present the Repair Plan

Output a prioritized findings table:

#	Severity	Rule violated	Location	Description
1	High	Independent & order-agnostic	account.spec.ts:14	account mutated across tests without beforeEach reset
2	Medium	Assert explicitly	account.spec.ts:42	toBeTruthy() used where exact value is known
3	Low	Independent & order-agnostic	account.spec.ts:8	jest.clearAllMocks() in beforeEach redundant — this package's jest.config.* already sets clearMocks: true (only flag when verified against the project config)

Severity:

• High — likely causes false positives, order-dependent failures, or masks real regressions (shared mutable state, missing await, over-mocking)
• Medium — reduces test value or maintainability (vague assertions, non-deterministic values, implementation-detail testing)
• Low — noise or convention violations that don't affect correctness (redundant calls, vague names, minor patterns)

Follow the table with a detailed write-up for each High finding, including a before/after code snippet showing the repair.

For Medium and Low findings, a one-line description and the repair snippet is sufficient.

---

Step 5: Suggest Scope

After presenting findings, suggest a reasonable repair scope based on the volume of issues:

• Few issues (1–5): Suggest fixing all in one pass.
• Moderate (6–15): Suggest prioritizing High findings first; Medium/Low in a follow-up.
• Many (16+): Suggest tackling by rule category across the file rather than line-by-line, and note that /fxa-test-independence should be run after repairs to validate nothing regressed.

Remind the engineer: repairs are suggestions. Review each one — especially mock restructuring, which can change test behavior, not just style.