pest-testing

Enforces Pest testing conventions for Laravel projects including coverage and mocking rules.

Updated Aug 25, 2017
One-click install
npx skills add https://github.com/loki495/dotfiles --skill pest-testing-loki495
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pest-testing
Source: https://github.com/loki495/dotfiles/tree/main/ai/skills/pest-testing
Command: npx skills add https://github.com/loki495/dotfiles --skill pest-testing-loki495

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing consistent, trustworthy Pest tests in Laravel projects is hard when conventions drift: PHPUnit syntax creeps in, happy-path-only coverage hides bugs, and tests get edited to force a green suite. This Skill codifies the team's Pest testing rules so every test written or audited follows the same standard. ## Core Features & Use Cases - Pest syntax enforcement: Requires it(), test(), describe() blocks and the expect() expectation API, never PHPUnit class-based syntax. - Coverage rules: Mandates both happy-path and sad-path tests per action, with sad paths asserting the correct handled outcome (422, specific exception, redirect with flash error) rather than just a status code. - Third-party API mocking: Directs use of Http::fake() for network calls, with sandbox credentials and idempotency rules when real API hits are unavoidable. - Hard rule against test tampering: Prohibits deleting, weakening, or skipping tests to make a failing suite pass; failures must be fixed in code or escalated. - Use Case: When asked to write tests for a new Laravel action, the Skill produces Pest tests calling handle() directly with factory-built data, covering valid input, validation failures, and mocked third-party failures. ## Quick Start Write Pest tests for this Laravel action covering both the happy path and validation failure cases, mocking any external API calls with Http::fake().

Frequently Asked Questions about pest-testing

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

FAQPage Schema
How do I write Pest tests for Laravel actions?▼

Write Pest tests using it(), test(), and describe() blocks with the expect() expectation API, never PHPUnit class syntax. Call the action's handle() method directly and assert on the returned result, grouping related tests in describe() blocks.

How to mock third-party API calls in Laravel tests?▼

Mock third-party calls with Http::fake() or the relevant fake instead of hitting real services. If a real hit is necessary, use the provider's sandbox endpoint or test mode, keep the test idempotent, and avoid consuming paid credits.

What is happy path and sad path test coverage?▼

Happy path coverage tests valid input with expected success, while sad paths test invalid input, failed validation, unauthorized access, and third-party failures. Sad-path tests must assert the correct handled outcome, such as a 422 with validation errors, not just any response.

Should I use RefreshDatabase with SQLite or MySQL in tests?▼

Use the RefreshDatabase trait on feature tests that touch the database. Confirm which driver the project uses first, since SQLite in-memory is common for fast local runs but some SQL features behave differently between SQLite and MySQL.

Can I edit or skip a failing test to make the suite pass?▼

No. Tests must never be deleted, have assertions weakened, or be skipped to force a pass without explicit confirmation. The default action is to fix the underlying code or flag the conflict and ask how to proceed.

Does this Pest convention apply to OpenCart projects?▼

No, these conventions apply to Laravel projects only. OpenCart projects are excluded unless a project explicitly opts in through its own .claude/project.md configuration.