- Home
- Skills
- J Morgan6
- Elixir Phoenix Guide
- Testing Essentials
testing-essentials_skill
- Shell
56
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill j-morgan6/elixir-phoenix-guide --skill testing-essentials- SKILL.md3.7 KB
Overview
This skill enforces a mandatory testing boilerplate and workflow for every _test.exs file. It codifies test structure, fixture usage, and LiveView/controller conventions so tests are consistent, maintainable, and safe to run concurrently. Use it as the first step before writing any test file to avoid common pitfalls and missing checks.
How this skill works
Invoke the skill before creating or editing any test file; it validates that the test module uses the appropriate Case (DataCase or ConnCase), imports fixtures and helpers, and follows TDD and fixture patterns. It also guides LiveView assertions to use element helpers, enforces unauthorized-path checks, and ensures both happy-path and error-path tests exist. The skill produces a minimal, consistent test skeleton and reminders for async, fixtures, and describe grouping.
When to use it
- Before creating any _test.exs file
- When starting TDD for a new feature or context
- When adding LiveView or controller tests
- When writing tests that touch the database or shared state
- When establishing consistent fixtures and test structure
Best practices
- Always pick DataCase for context/schema tests and ConnCase for LiveView/controllers — never mix them
- Write the failing test first, run it, then implement the minimum to pass (TDD)
- Put all test data in fixtures under test/support/fixtures and reuse them across tests
- Use async: true only when tests do not touch shared state or external services
- Assert LiveView structure with has_element?/2 and element/2 rather than string matching HTML
- Group tests with describe blocks and always include unauthorized/error cases
Example use cases
- Create a new accounts context: run a failing test using DataCase, implement minimal code to pass
- Add LiveView form tests: use ConnCase, import LiveView test helpers, and assert with has_element?/2
- Test changeset validations: assert valid? and use errors_on to verify required fields
- Protect admin routes: write a test that verifies unauthorized users are redirected to login
- Refactor fixtures into test/support/fixtures and update tests to use the shared factory functions
FAQ
No. Use DataCase for pure context/schema tests and ConnCase for LiveView or controller tests; mixing them increases complexity and incorrect setup.
When is async: true safe to use?
Use async: true only for tests that do not touch shared state (database tables without sandbox transactions) or external services. If tests interact with shared resources, run them synchronously.
Should I assert HTML with =~ for LiveView tests?
Avoid =~ for structure checks. Use LiveView helpers like has_element?/2 and element/2 to assert presence and structure reliably.