Exunit code review

Skill existential-birds/beagle/plugins/beagle-elixir/skills/exunit-code-review

Agent Skills marketplace: framework-aware skills for code review, documentation, test-plan generation, AI-writing detection, architectural analysis, and git workflows — for Python, Go, Rust, Elixir, React, Remix, and iOS/Swift. Works with Claude Code, Codex, and any agent that supports Agent Skills.

Install

npx -y skills add existential-birds/beagle --skill exunit-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

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

SKILL.md

3.4 KB, as published. Nobody here has run it

ExUnit 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: 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.

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.