custom-laravel-writing-tests

Writes Laravel Pest tests following TDD workflow and project testing conventions.

1|Updated Apr 3, 2021
One-click install
npx skills add https://github.com/NaoyaMiyagawa/dotfiles --skill custom-laravel-writing-tests-naoyamiyagawa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: custom-laravel-writing-tests
Source: https://github.com/NaoyaMiyagawa/dotfiles/tree/main/.ai/skills/custom-laravel-writing-tests
Command: npx skills add https://github.com/NaoyaMiyagawa/dotfiles --skill custom-laravel-writing-tests-naoyamiyagawa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing consistent, maintainable Pest tests in a Laravel project requires remembering dozens of conventions — test file naming, describe block structure, dataset shapes, factory usage, and assertion idioms. This Skill encodes those rules so every test you write or update follows the same standard and passes a mandatory style review gate. ## Core Features & Use Cases - TDD Workflow Enforcement: Guides test-first development using the t_wada red-green-refactor cycle, including characterisation tests before refactoring uncovered code. - 15 Core Testing Rules: Covers test file naming (one file per production class), describe-per-method structure, AAA markers, beforeEach shape, feature request style, assertion patterns, datasets, and thin controller tests. - Long-Tail Checklist: A references/checklist.md file details factories, mocks, datasets, event listeners, regression tests, and contract-drift tests, enforced by a mandatory review gate on every test diff. - Use Case: When adding a feature test for a new invoice endpoint, the Skill ensures you build URLs with route(), chain assertions correctly, group cases in request-flow order, and mock delegated services rather than re-covering their logic. ## Quick Start Write a Pest feature test for the invoice store endpoint following the project's Laravel testing conventions.

Frequently Asked Questions about custom-laravel-writing-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Pest feature tests for Laravel controllers?

Keep controller tests thin: one success case asserting the delegate receives the right arguments, validation cases, one rejection case, and authorization cases. Build URLs with route(), chain assertions off the request, and mock delegated Actions or Services rather than re-covering their logic.

How should Pest datasets be structured for validation tests?

Consolidate validation cases into a single dataset with a column for the expected error message. Use closure columns for per-case arrange logic, and wrap the entire row in a closure when it needs $this state from beforeEach, since per-column closures lack that binding.

What is the correct beforeEach structure in Pest tests?

Create local variables first, then assign them to $this properties. Call actingAs() once when every case uses the same user, place fakes like Queue::fake() in beforeEach when the method dispatches jobs, and resolve the class under test with app() at each call site.

Should I use toBe or toEqual for Pest assertions?

Use toBe for scalars and enums, and toEqual for arrays and objects where key order and instance identity are not part of the contract. For datetimes, compare via toDateTimeString() to survive Carbon versus CarbonImmutable cast mismatches.

When should I not write a test for Laravel code?

Skip tests for framework or library behaviour, Resources, DTOs, and Events. Policy tests are unnecessary when controller authorization blocks already cover them, unless controller tests mock the policy or only assert it is wired.