testing-philosophy

Enforces test-driven development discipline with red-green-refactor workflow and suite health rules.

4|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/laicluse/agent-fieldkit --skill testing-philosophy-laicluse
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-philosophy
Source: https://github.com/laicluse/agent-fieldkit/tree/main/.agents/plugins/generated/house-rules/skills/testing-philosophy
Command: npx skills add https://github.com/laicluse/agent-fieldkit --skill testing-philosophy-laicluse

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often write tests after implementation, skip specs for "trivial" changes, tolerate flaky or failing suites, and accumulate scar-tissue tests that bloat the suite. This Skill codifies a strict testing philosophy so specs define behavior before code exists and the suite stays trustworthy. ## Core Features & Use Cases - Mandatory TDD workflow: Enforces red-green-refactor for every feature, bugfix, and interface change, with bug reproduction specs verified by reverting the fix. - Suite hygiene rules: Defines absence pinning, scar tissue, spec scaffolding, and mass test deletion as smells, with criteria for when a test earns its place. - Layered coverage guidance: Distinguishes end-to-end behavior tests for UI bugs from unit specs for services, jobs, and external-IO wrappers, plus declarative Gherkin scenario style. - Use Case: When fixing a bug where a voucher is double-charged, write a failing reproduction spec first, apply the fix, then revert the fix to confirm the spec fails again before committing. ## Quick Start Apply the testing-philosophy skill to write a failing spec for this bug before implementing any fix.

Frequently Asked Questions about testing-philosophy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I practice test-driven development for bugfixes?▼

Write a spec that reproduces the bug and watch it fail, then fix the bug so the spec turns green. Verify by reverting the fix and confirming the spec fails again, proving the spec actually guards the behavior.

When should I write end-to-end tests instead of unit tests?▼

Write end-to-end behavior tests for bugs involving user interaction like buttons, forms, and navigation. Unit specs cover server-side logic such as services, background jobs, and external-IO wrappers whose internal contracts e2e tests cannot reach.

Should I write a test asserting removed code stays removed?▼

No, that is absence pinning and it bloats the suite without guarding behavior. The exception is an exploitable leftover with a named risk, such as an auth bypass or vestigial endpoint, which justifies a deliberate guard spec.

What should I do when I encounter a flaky test?▼

Stop current work and hand the flaky spec to a dedicated investigation with the spec path, run command, error output, failure rate, and a cause hypothesis. Never retry until green or fix it as a side task during other work.

Can I commit code while the test suite has pre-existing failures?▼

No, failing specs block everything regardless of origin. Investigate and fix the failures to get the suite green before committing or deploying; dismissing failures as pre-existing is forbidden.

Is it acceptable to delete tests during a refactor?▼

Only when you can map each deleted test to where its behavior is now covered, such as another unit file or e2e scenario. Mass-deleting tests without that mapping is a smell indicating dodged failures, not suite curation.