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 configurations.
git clone --depth 1 https://github.com/existential-birds/beagle /tmp/exunit-code-review && cp -r /tmp/exunit-code-review/plugins/beagle-elixir/skills/exunit-code-review ~/.claude/skills/exunit-code-reviewSKILL.md
# ExUnit Code Review ## Quick Reference | Issue Type | Reference | |------------|-----------| | Async tests, setup, describe, tags | [references/exunit-patterns.md](references/exunit-patterns.md) | | Behavior-based mocking, expectations | [references/mox-boundaries.md](references/mox-boundaries.md) | | Bypass, Swoosh, Oban testing | [references/test-adapters.md](references/test-adapters.md) | | What to mock vs real, Ecto sandbox | [references/integration-tests.md](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](../review-verification-protocol/SKILL.md) (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.
tag and push a release after the release PR is merged
create a release PR (auto-detects previous tag)
Guides architectural decisions for Deep Agents applications. Use when deciding between Deep Agents vs alternatives, choosing backend strategies, designing subagent systems, or selecting middleware approaches.
Reviews Deep Agents code for bugs, anti-patterns, and improvements. Use when reviewing code that uses create_deep_agent, backends, subagents, middleware, or human-in-the-loop patterns. Catches common configuration and usage mistakes.
Implements agents using Deep Agents. Use when building agents with create_deep_agent, configuring backends, defining subagents, adding middleware, or setting up human-in-the-loop workflows.
Guides architectural decisions for LangGraph applications. Use when deciding between LangGraph vs alternatives, choosing state management strategies, designing multi-agent systems, or selecting persistence and streaming approaches.
Reviews LangGraph code for bugs, anti-patterns, and improvements. Use when reviewing code that uses StateGraph, nodes, edges, checkpointing, or other LangGraph features. Catches common mistakes in state management, graph structure, and async patterns.
Implements stateful agent graphs using LangGraph. Use when building graphs, adding nodes/edges, defining state schemas, implementing checkpointing, handling interrupts, or creating multi-agent systems with LangGraph.