testing-essentials_skill

This skill helps teams enforce Elixir testing best practices by providing structured guidance, fixtures, and test structure rules before writing tests.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
testing-essentials skill by j-morgan6/elixir-phoenix-guide | VeilStrat