tdd
tdd guides you through writing tests before implementation using the red-green-refactor workflow. Each cycle commits a failing test marked red, then minimal passing code marked green, with refactoring only after all tests pass. The skill enforces behavioral testing over implementation details and includes commit hygiene checks to keep your tree lint-clean at every step.
tdd teaches the red-green-refactor cycle: write a failing test, commit it, implement minimally to pass, commit green, then refactor.
AI-generated summary based on this skill's SKILL.md
Decision gist · record as of 2026-07-27
tdd teaches the red-green-refactor cycle: write a failing test, commit it, implement minimally to pass, commit green, then refactor. tdd guides you through writing tests before implementation using the red-green-refactor workflow. Each cycle commits a failing test marked red, then minimal passing code marked green, with refactoring only after all tests pass. The skill enforces behavioral testing over implementation details and includes commit hygiene checks to keep your tree lint-clean at every step.
Use it when
- tdd teaches you to write failing tests before any implementation.
- tdd enforces a commit protocol where each phase—red test, green code, refactoring—gets its own commit.
Verify before relying
Read SKILL.md below before installing (8 files). Open directory: indexed for reading, not audited.
Install
frankify-app/skills/tdd · repository language: Shell
Open directory. Skills are indexed for reading, not audited. Review a skill's body before installing it.
Frequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
What is the red green refactor cycle in tdd?
tdd's red-green-refactor cycle is the core workflow: first write a failing test (red), then write minimal code to make it pass (green), then refactor safely knowing tests still pass. Each phase gets its own commit, creating an auditable history where every commit is either a failing test, passing code, or a refactoring. This discipline keeps your tree lint-clean and your changes traceable.
How do I write tests first with tdd?
tdd teaches you to write failing tests before any implementation. Start by describing the behavior you want in a test, run it to confirm it fails (red phase), then write just enough code to pass it (green phase). This inverts traditional development: the test becomes your specification. tdd guides you to focus on what the code should do, not how it does it, preventing over-engineering.
How should I structure tdd commits for auditable test history?
tdd enforces a commit protocol where each phase—red test, green code, refactoring—gets its own commit. This creates an auditable history showing exactly when tests were added and when implementation followed. The skill includes commit hygiene checks to keep your repository lint-clean at every step, making it easy to review or bisect changes later.
What testing anti-patterns should I avoid in tdd?
tdd helps you sidestep common pitfalls: testing implementation details instead of behavior, writing tests after code (defeating TDD's design benefits), or skipping refactoring. The skill teaches behavioral testing that survives refactoring, so your tests describe what the code does, not how. Avoid brittle tests tied to internal structure; tdd guides you toward resilient, maintainable test suites.
Can tdd help with vertical-slice testing instead of layers?
tdd includes guidance on vertical-slice testing, where you test a complete feature end-to-end rather than isolated horizontal layers. This approach often catches real integration issues earlier and keeps tests closer to user behavior. tdd's behavioral focus naturally aligns with vertical slices, helping you write tests that matter.
How does tdd ensure tests don't become brittle after refactoring?
tdd emphasizes behavioral testing over implementation details, so your tests describe outcomes, not internal mechanics. When you refactor during the refactor phase (with all tests passing), behavioral tests remain valid because the external contract hasn't changed. This discipline means your test suite survives refactoring intact, supporting long-term code health.
SKILL.md
Rendered from the published skill. Quoted content, verbatim.
Test-Driven Development
Write test first. Commit it red. Write minimal code to pass. Commit green. Refactor.
Core principle: tests verify behavior through public interfaces, not implementation. Code can change entirely; tests shouldn't. A test that breaks when you rename an internal function — with no behavior change — was testing implementation.
(truncated - see the full file via the links below)
File tree — 8 files
derived/tdd/SKILL.md
derived/tdd/deep-modules.md
derived/tdd/interface-design.md
derived/tdd/lint-red.sh
derived/tdd/mocking.md
derived/tdd/refactoring.md
derived/tdd/testing-anti-patterns.md
derived/tdd/tests.md
Let your AI agent find skills like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 56,283 agent skills by what they can do, searchable in plain language.
wish › “Learn and implement test-driven development workflow with red-green-refactor”
Give your agent the search over MCP, or paste the wish link into any chat. No install? Search from any chat →
Related skills
This skill teaches the red-green-refactor cycle: write a failing test, verify it fails for the right reason, implement just enough code to pass, then refactor. Follow the iron law—no production code without a failing test first—and use this approach for all features, bug fixes, and refactoring work.
tdd guides you through strict test-driven development using the red-green-refactor cycle: write a failing test, implement minimal code to pass it, then refactor. The skill enforces the discipline of writing tests before production code and provides framework-specific commands for multiple languages.
TDD Mastery enforces the iron law of test-first development: write a failing test, verify it fails, implement minimal code to pass, then refactor. The skill drills the red-green-refactor cycle with no exceptions, rejecting any production code written before its corresponding test exists and has been observed failing.
This skill guides you through test-driven development using separate subagents for test writing and implementation, ensuring each phase stays focused on its role. It supports Jest, Vitest, pytest, Go test, cargo test, PHPUnit, and RSpec, with modes for interactive approval, autonomous execution, and dry-run validation. Vertical slicing and context isolation keep your TDD workflow disciplined and your tests honest.
This skill activates during OpenSpec change implementation to enforce atomic test-driven development: every test—acceptance, unit, edge case, or helper—must fail for the right reason before production code is written to make it pass. Gherkin scenarios in spec.md are the canonical acceptance contract; every relevant scenario must become at least one test. The per-test state machine forbids batching, skipping refactor assessment, or shipping with uncovered scenarios.
Test Driven Development teaches the red-green-refactor discipline for writing code validated by tests before implementation. Learn when to apply TDD across feature work, bug fixes, and refactoring, plus how to design testable interfaces, mock at system boundaries, and avoid common pitfalls.
More skills domain-modeling (MIT) · rtk-tdd (Apache-2.0) · tdd-rust (Apache-2.0)