Exunit Code Review

Reviews ExUnit test code for proper patterns, boundary mocking with Mox, and test adapter usage. Use when reviewing _test.exs files or test helper configurat...

Security Scan

The skill is an instruction-only ExUnit test-review checklist that only requires reading test files and provides line-tied review rules; its requests and instructions align with its stated purpose.

Purpose & Capability

Name and description (ExUnit test review) match the content: the skill is instruction-only, contains reference docs about ExUnit/Mox/Bypass/Oban, and declares no binaries, env vars, or installs that would be unrelated to test review.

Instruction Scope

SKILL.md instructs the agent to open test modules/helpers, produce findings tied to concrete file:line evidence, and perform repository-local checks (read blocks, search usages). Those actions are appropriate and proportionate for a code-review skill; the instructions do not request credentials or external network endpoints.

Install Mechanism

No install spec or code files to run; instruction-only distribution means nothing is written to disk or downloaded during install — lowest-risk delivery mechanism for this purpose.

Credentials

No required environment variables, credentials, or config paths are declared or referenced. The recommended actions (reading test files) are consistent with not needing secrets or external credentials.

Persistence & Privilege

always is false and the skill does not request persistent system changes or modify other skills. It allows normal autonomous invocation (disable-model-invocation: false) which is the platform default and acceptable here.

Assessment

This skill appears coherent for reviewing ExUnit test files: it will read your repository's test modules and helpers to produce line-referenced findings. Before installing, confirm you're comfortable with the agent reading your test files (it does not request credentials or perform installs). If you handle sensitive data in tests, consider running reviews locally or ensuring the agent's model/process does not send repository contents to external services you don't trust. If you want stricter control, you can keep autonomous invocation disabled at the agent level or manually invoke the skill when needed.

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: true unless 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.

1. 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.

2. 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.

3. 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.