playbooks

home / skills / makfly / superpowers-symfony / test-doubles-mocking

test-doubles-mocking skill

/skills/test-doubles-mocking

This skill helps you drive Symfony test doubles mocking with deterministic tests, safeguarding regression coverage across fail and pass paths.

npx playbooks add skill makfly/superpowers-symfony --skill test-doubles-mocking

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
1.1 KB
---

name: symfony:test-doubles-mocking
allowed-tools:
  - Read
  - Glob
  - Grep
description: Drive Symfony delivery with deterministic tests and strong regression protection. Use for test doubles mocking tasks.
---

# Test Doubles Mocking (Symfony)

## Use when
- Building regression-safe behavior with TDD/functional/e2e tests.
- Converting bug reports into executable failing tests.

## Default workflow
1. Write failing test for target behavior and one boundary case.
2. Implement minimal code to pass.
2. Refactor while preserving green suite.
2. Broaden coverage for invalid/unauthorized/not-found paths.

## Guardrails
- Prefer deterministic fixtures/builders.
- Assert observable behavior, not internal implementation.
- Keep tests isolated and stable in CI.

## Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.

## Output contract
- RED/GREEN/REFACTOR trace.
- Test files changed and executed commands.
- Coverage and confidence notes.

## References
- `reference.md`
- `docs/complexity-tiers.md`

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

What does the RED/GREEN/REFACTOR trace include?

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.