- Home
- Skills
- Makfly
- Superpowers Symfony
- Functional Tests
functional-tests_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 functional-tests- reference.md624 B
- SKILL.md1.1 KB
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
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.