home / skills / makfly / superpowers-symfony / functional-tests

functional-tests skill

safe

This skill helps you drive Symfony functional tests with deterministic fixtures, regression-focused workflow, and clear red/green/refaactor signals.

npx playbooks add skill makfly/superpowers-symfony --skill functional-tests

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:functional-tests
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Drive Symfony delivery with deterministic tests and strong regression protection. Use for functional tests tasks.
---

# Functional Tests (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 drives Symfony delivery using deterministic functional tests to provide strong regression protection. It focuses on building tests that represent real behavior, converting bugs into failing tests, and enforcing a RED/GREEN/REFACTOR workflow. The goal is reliable CI results and clear traces of test-driven changes.

How this skill works

The skill orchestrates writing and running Symfony functional/e2e tests, insisting you start with a failing test, implement minimal code, then refactor while keeping the suite green. It inspects test files, executed commands, and produces a RED/GREEN/REFACTOR trace plus notes on test changes, coverage, and confidence. It enforces guardrails like deterministic fixtures, isolated tests, and assertions on observable behavior rather than internals.

When to use it

Adopting TDD or strengthening functional/e2e coverage for a Symfony app
Converting a bug report into an executable failing test before fixing
Protecting critical delivery paths from regressions in CI
Validating HTTP flows, authentication, and API contracts
Ensuring deterministic CI runs for delivery pipelines

Best practices

Write a failing test and one boundary case before code changes
Use deterministic fixtures or builders to avoid flaky tests
Assert on observable behavior (responses, DB state) not internal implementation details
Keep tests isolated, fast, and stable under CI
Broaden coverage after green: invalid inputs, unauthorized access, not-found cases

Example use cases

Create a failing functional test from a production bug and drive the fix through RED/GREEN/REFACTOR
Add end-to-end coverage for a new API endpoint with deterministic fixtures
Harden login and authorization flows with isolated tests that run reliably in CI
Convert manual regression checks into automated functional tests for deployment gates
Measure confidence by recording executed test files, commands, and coverage notes in delivery logs

FAQ

What output should I expect from this skill?

You get a RED/GREEN/REFACTOR trace, a list of test files changed, the executed commands, and coverage/confidence notes.

How do I avoid flaky tests?

Prefer deterministic fixtures/builders, isolate tests, avoid external network calls in tests, and assert observable outcomes rather than internals.

When should I broaden coverage?

After you have a green suite for the target behavior, add invalid, unauthorized, and not-found scenarios to reduce regression risk.