tdd

Enforce test-driven development with a red-green-refactor workflow.

4|Updated Apr 13, 2026
One-click install
npx skills add https://github.com/Ni-Bu/skills --skill tdd-ni-bu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/Ni-Bu/skills/tree/main/tdd
Command: npx skills add https://github.com/Ni-Bu/skills --skill tdd-ni-bu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you build features and fix bugs through a disciplined test-driven development loop, so behavior stays correct while the code evolves.

Core Features & Use Cases

  • Behavior-first testing: Focuses tests on public interfaces and observable outcomes instead of internal implementation details.
  • Red-green-refactor workflow: Guides you through writing one failing test, implementing the minimum change, and then refactoring safely after the suite is green.
  • Design and refactoring support: Reinforces deep modules, testable interfaces, and boundary-only mocking to keep tests stable through future changes.
  • Use case: Ideal when you are adding a feature, fixing a bug, or untangling a module and want the work to stay organized around small, verifiable behavioral steps.

Quick Start

Use the tdd skill to define the public interface and the next behavior to test, then write one failing test, make the smallest change to pass it, and repeat until the feature is complete.

Frequently Asked Questions about tdd

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

FAQPage Schema
How do I start behavior-first testing when adding a new feature?

Behavior-first testing starts by defining the public interface and the next observable outcome, then writing one failing test for that behavior before making the smallest code change to pass it.

What's the best way to structure a red-green-refactor workflow for bug fixing?

A red-green-refactor workflow for bug fixing involves writing a single failing test that reproduces the bug, implementing the minimum change to turn the suite green, and then safely refactoring the code.

Why does my test suite break frequently after refactoring internal implementation details?

Test suites break after refactoring because tests are coupled to internal implementation details rather than public interfaces, violating behavior-first testing principles and reducing module stability.

When should I use boundary-only mocking in test-driven development?

Boundary-only mocking should be used when test-driven development requires isolating external dependencies at the system boundary, ensuring tests remain stable and focused on observable behavior rather than internal interactions.

Can I untangle a complex module using incremental refactoring and TDD?

You can untangle a complex module using TDD by progressing one test at a time, enforcing deep modules and testable interfaces, and applying safe refactor steps only after the test suite turns green.