tdd

Enforce the red-green-refactor cycle with public interface seams for testing.

Updated Dec 17, 2025
One-click install
npx skills add https://github.com/Frantss/oxform --skill tdd-frantss
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/Frantss/oxform/tree/main/.agents/skills/tdd
Command: npx skills add https://github.com/Frantss/oxform --skill tdd-frantss

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This skill addresses the common struggle of writing tests that are either too coupled to implementation details or fail to provide meaningful verification of user-facing behavior.

Core Features & Use Cases

  • Red-Green-Refactor Guidance: Provides a structured approach to the TDD loop, ensuring tests are written before implementation and refactoring is handled as a distinct phase.
  • Seam Identification: Helps define public boundaries for testing, preventing the common anti-pattern of testing internal private methods.
  • Best Practices: Offers clear guidelines on mocking at system boundaries and avoiding tautological assertions.

Quick Start

Ask the agent to help you define the public seams for your current feature and write a failing test case before you begin implementation.

Frequently Asked Questions about tdd

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

FAQPage Schema
How do I start the test-driven development cycle for a new feature?

To start test-driven development, define the public seams for your feature and write a failing test case before writing any implementation code. This enforces the red-green-refactor loop, ensuring tests drive behavior-driven design from the very beginning.

Why does my unit testing fail when I refactor internal implementation details?

Your unit testing fails during refactoring because tests are too coupled to internal private methods rather than public interface seams. By verifying behavior through independent sources of truth, you can refactor code without breaking existing test assertions.

What is the best way to write integration tests without testing private methods?

The best way to avoid testing private methods during integration testing is to identify and verify public interface seams. This behavior-driven design approach decouples tests from internal implementation details, maintaining independent sources of truth for assertions.

When should I use mocking in unit testing to avoid tautological assertions?

Use mocking in unit testing strictly at system boundaries to avoid tautological assertions. This practice ensures tests provide meaningful verification of user-facing behavior rather than simply mirroring the internal logic of the implementation.

Can I apply the red-green-refactor loop to both unit and integration testing scenarios?

Yes, the red-green-refactor loop applies to both unit and integration testing scenarios. It enforces writing tests before implementation and treats refactoring as a distinct phase, prioritizing code quality and maintainability across all testing levels.