- Home
- Skills
- Makfly
- Superpowers Symfony
- Test Doubles Mocking
test-doubles-mocking_skill
- Shell
69
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 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 makfly/superpowers-symfony --skill test-doubles-mocking- reference.md7.5 KB
- SKILL.md1.1 KB
Overview
This skill helps teams drive Symfony delivery with deterministic tests and strong regression protection by focusing on test doubles and mocking. It guides a RED/GREEN/REFACTOR workflow that produces repeatable, isolated tests and clear change traces. The skill emphasizes observable behavior, stable CI results, and incremental coverage expansion.
How this skill works
It inspects test plans and existing suites to recommend and apply test doubles, mocks, and deterministic fixtures that reduce flakiness. The skill generates the failing test, suggests minimal implementation changes to get green, then advises safe refactors and broader coverage for edge cases. Outputs include a RED/GREEN/REFACTOR trace, list of changed test files and executed commands, and notes on coverage and confidence.
When to use it
- Driving behavior with TDD or acceptance-first workflows
- Converting a bug report into an executable failing test
- Stabilizing flaky or non-deterministic integration tests in CI
- Adding regression protection around business-critical flows
- Mocking external services or slow dependencies in functional tests
Best practices
- Prefer deterministic fixtures and builders instead of ad-hoc state setup
- Assert observable outcomes (HTTP response, state changes), not internal mocks' implementation
- Keep tests isolated: avoid shared global state and point-in-time dependencies
- Start with a failing test and one boundary case before implementing
- Broaden coverage after green: invalid, unauthorized, and not-found paths
Example use cases
- Write a failing functional test that reproduces a reported bug and implement the minimal fix
- Replace live service calls with controlled test doubles for CI stability
- Create builders for domain entities to make tests deterministic and readable
- Add end-to-end tests that mock third-party APIs to avoid rate limits and flakiness
- Refactor controller or service internals while keeping the public behavior covered by tests
FAQ
A concise record showing the failing test(s) introduced, commands run to execute them, the minimal code changes to pass, and any refactoring steps taken.
How do I keep mocks from coupling tests to implementation?
Mock only external interactions and assert public observable behavior. Favor fixtures and builders that express intent rather than mocking internal methods.