Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/garrettw/php-arch-skills/testing-strategynpx skills add garrettw/php-arch-skills --skill testing-strategygit clone --depth 1 https://github.com/garrettw/php-arch-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/garrettw/php-arch-skills/testing-strategy)<a href="https://agentmods.dev/skills/garrettw/php-arch-skills/testing-strategy"><img src="https://agentmods.dev/badge/skills/garrettw/php-arch-skills/testing-strategy.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00046 | $0.01274 |
| Opus 5 | $0.00023 | $0.00637 |
| Sonnet 5 | $0.00009 | $0.00255 |
| Haiku 4.5 | $0.00005 | $0.00127 |
Grade A, and why
testing-strategy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Backend Testing Strategy by Architecture Layer
System Overview
Different architectural layers have different responsibilities, and tests should be structured to verify those specific responsibilities without over-specifying internal implementation details. This skill provides rules for matching the right testing style (unit, integration, feature) to the correct layer.
Principles Behind Good Tests
- Arrange, Act, Assert (AAA). One logical flow per test: set up the scenario, perform the one action under test, assert the outcome. Keep the "Given" visibly in the test body.
- Isolation. Each test owns its data and runs independently of others, in any order. No shared mutable state, no order dependence. Deterministic tests are the only ones worth having.
- Mock only at boundaries. Replace slow or non-deterministic collaborators (databases, HTTP, queues) with doubles. Do not mock the database inside a repository test (test the repository against a real test DB) and do not mock the very object under test. Mocking everything while asserting on call order verifies the implementation, not the behavior — a brittle test that breaks on every refactor.
- Assert behavior, not internals. Assert on the resulting state, returned value, or recorded events — not on private methods or the exact internal call sequence. A test that survives a legitimate refactor is a test worth keeping.
- Coverage is a guide, not a target. Aim for meaningful coverage of business logic and unhappy paths; 100% is not the goal and can incentivize worthless assertions.
See clean-code-foundations.md for the encapsulation/DRY lenses that apply here.
Numbered Workflows
1. Testing the Domain Layer
If testing pure domain logic (entities, value objects, policies):
- Use pure PHP unit tests. Do not boot the framework or database.
- Setup state. Instantiate the object directly using
new(the "Given"). - Execute behavior. Call the domain method (the "When").
- Assert outcomes. Verify the new state, the returned result, or the events recorded (the "Then").
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 70 lines · 46 tokens per session scan A f33e12c2eb49
testing-strategy is a skill published in the GitHub repository garrettw/php-arch-skills (11 stars, last pushed 1mo ago), licensed MPL-2.0. It adds 46 tokens to every session and 1,274 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
edge-case-hunter
Focuses specifically on unusual inputs, boundary conditions, empty states, and unexpected user behavior that implementations commonly miss. Use to find what a normal test pass would skip over.
test-generator
Creates meaningful unit, integration, and component tests based on implementation and requirements. Use when code needs test coverage and you want tests that verify behavior, not just tests that pad a coverage number.
Test Engineer
Creates or completes a medium-coverage test suite: unit, component, and critical e2e flows.
swift
Swift development: concurrency patterns, async/await, actors, testing with XCTest and Swift Testing framework.
refactor
Refactors code for quality and maintainability. Triggers: refactor, clean up, restructure, improve code, modernize.
testing-patterns
Testing strategy: pyramid, AAA, mocks/fakes/stubs, flaky tests, coverage. Triggers: test, fixture, mock, stub, e2e, TDD, Playwright, Cypress, flaky, coverage, property-based.