exunit-code-review
About exunit-code-review
An ExUnit test code-review guide for Elixir teams, covering test structure, external-boundary mocks, test adapters, and database isolation. It sets review gates requiring file-line evidence and verification steps.
Key features
- 01Check async tests and test organization
- 02Use Mox only at external boundaries
- 03Review Bypass, Swoosh, and Oban test adapters
- 04Check Ecto sandbox database isolation
- 05Verify findings in sequence and cite line numbers
Use cases
- 01Review an ExUnit test module
- 02Decide whether external dependencies need mocks
- 03Check async tests and shared database state
- 04Submit review findings with file and line evidence
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/exunit-code-reviewin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/exunit-patterns.mdintegration-tests.mdmox-boundaries.mdtest-adapters.mdDetails
From the project READMEExUnit Code Review
Quick Reference
| Issue Type | Reference |
|---|---|
| Async tests, setup, describe, tags | references/exunit-patterns.md |
| Behavior-based mocking, expectations | references/mox-boundaries.md |
| Bypass, Swoosh, Oban testing | references/test-adapters.md |
| What to mock vs real, Ecto sandbox | references/integration-tests.md |
Mock Boundary Philosophy
Mock at external boundaries:
- HTTP clients, external APIs, third-party services
- Slow resources: file system, email, job queues
- Non-deterministic: DateTime.utc_now(), :rand
DO NOT mock internal code:
- Contexts, schemas, GenServers
- Internal modules, PubSub
- Anything you wrote
Review Checklist
Test Structure
- Tests are
async: trueunless sharing database state - Describe-blocks group related tests
- Setup extracts common test data
- Tests have clear arrange/act/assert structure
Mocking
- Mox used for external boundaries (HTTP, APIs)
- Behaviors defined for mockable interfaces
- No mocking of internal modules
- verify_on_exit! in setup for strict mocking
Test Adapters
- Bypass for HTTP endpoint mocking
- Swoosh.TestAdapter for email testing
- Oban.Testing for background job assertions
Database
- Ecto.Adapters.SQL.Sandbox for isolation
- Async tests don't share database state
- Fixtures/factories used consistently
Valid Patterns (Do NOT Flag)
- Mock in unit test, real in integration - Different test levels have different needs
- Not mocking database in integration tests - Database is internal
- Simple inline test data - Not everything needs factories
- Testing private functions via public API - Correct approach
Context-Sensitive Rules
| Issue | Flag ONLY IF |
|---|---|
| Not async | Test actually needs shared state |
| Missing mock | External call exists AND no mock/bypass |
| Mock internal | Module being mocked is internal code |
Gates (sequence)
Complete in order. Do not emit a finding until the prior step passes for that issue.
-
Evidence from the file — Open the test module (or helper) and tie the claim to concrete lines.
- Pass when: Each prospective finding includes
[FILE:LINE]and a one-line factual description of what is on that line (or an adjacent line you name), not a generic style complaint.
- Pass when: Each prospective finding includes
-
ExUnit false-positive veto — Check this skill’s Valid Patterns and Context-Sensitive Rules for the case.
- Pass when: You can state “not covered by Do NOT Flag / Flag ONLY IF” in one sentence, or you drop the finding.
-
Cross-protocol verification — Apply review-verification-protocol (e.g. read full function/block, search usages before “unused” claims) to that same finding.
- Pass when: At least one protocol check relevant to the claim type is satisfied and would appear in your rationale if challenged.
Before Submitting Findings
Use [FILE:LINE] ISSUE_TITLE per finding after Gates (sequence) and the linked protocol are satisfied.