testing

Solid

Elixir testing patterns — ExUnit, Mox, factories, LiveView test helpers. Use when working on *_test.exs, test/support/, factory files, or fixing test failures.

Testing & QA 384 stars 25 forks Updated 4 days ago MIT

Install

View on GitHub

Quality Score: 95/100

Stars 20%
86
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Elixir Testing Reference Quick reference for Elixir testing patterns. ## Iron Laws — Never Violate These 1. **ASYNC BY DEFAULT** — Use `async: true` unless tests modify global state 2. **SANDBOX ISOLATION** — All database tests use Ecto.Adapters.SQL.Sandbox 3. **MOCK ONLY AT BOUNDARIES** — Never mock database, internal modules, or stdlib 4. **BEHAVIOURS AS CONTRACTS** — All mocks must implement a defined `@callback` behaviour 5. **BUILD BY DEFAULT** — Use `build/2` in factories; `insert/2` only when DB needed 6. **NO PROCESS.SLEEP** — Use `assert_receive` with timeout for async operations 7. **VERIFY_ON_EXIT!** — Always call in Mox tests setup 8. **FACTORIES MATCH SCHEMA REQUIRED FIELDS** — Factory definitions must include all fields that have `validate_required` in the schema changeset. Missing fields cause cascading test failures ## Quick Decisions ### Which Test Case? | Testing | Use | |---------|-----| | Controller/API | `use MyAppWeb.ConnCase` | | Context/Schema | `use MyApp.DataCase` | | LiveView | `use MyAppWeb.ConnCase` + `import Phoenix.LiveViewTest` | | Pure logic | `use ExUnit.Case, async: true` | ### When to use async: true? - ✅ Pure functions, no shared state - ✅ Database tests with Sandbox (PostgreSQL) - ❌ Tests modifying `Application.put_env` - ❌ Tests using Mox global mode ### Mock or not? - ✅ Mock: External APIs, email services, file storage - ❌ Don't mock: Database, internal modules, stdlib ### build() or insert()? - Use `build()` by default fo...

Details

Author
oliver-kriska
Repository
oliver-kriska/claude-elixir-phoenix
Created
3 months ago
Last Updated
4 days ago
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Testing & QA Solid

test-patterns

Applies proven testing patterns — Arrange-Act-Assert (AAA), Given-When-Then, Test Data Builders, Object Mother, parameterized tests, fixtures, spies, and test doubles — to help write maintainable, reliable, and readable test suites. Use when the user asks about writing unit tests, integration tests, or end-to-end tests; structuring test cases or test suites; applying TDD or BDD practices; working with mocks, stubs, spies, or fakes; improving test coverage or reducing flakiness; or needs guidance on test organization, naming conventions, or assertions in frameworks like Jest, Vitest, pytest, or similar.

1,177 Updated today
rohitg00
Testing & QA Listed

principle-testing

Testing strategy and architecture — test pyramid (unit / integration / e2e), test doubles taxonomy (stub / mock / spy / fake), coverage-vs-confidence, mutation testing, flaky-test triage, contract testing, property-based and characterization tests, fixtures and test data builders. Distinct from principle-tdd which covers the red-green-refactor micro-cycle. Auto-load when discussing test strategy, mock vs real dependency, coverage adequacy, test pyramid balance, flaky test diagnosis, contract testing, or test architecture.

2 Updated today
lugassawan
Testing & QA Listed

testing

Testing strategies, patterns, and best practices

0 Updated today
murtazatouqeer
Testing & QA Listed

unit-testing

Unit testing patterns: Vitest config with v8 coverage, Testing Library behavior testing, MSW for HTTP mocking (vs jest.mock), it.each parametrized tests, spies vs mocks vs stubs, testing async code, snapshot testing guidelines. Use when writing unit and component tests.

13 Updated 2 months ago
rnavarych
Testing & QA Listed

oracle-testing

Stub-Driven TDD and layer boundary testing. Use when writing tests, deciding what to test, or testing at component boundaries.

28 Updated 1 weeks ago
martinffx