tdd-workflow

Enforce test-driven development and consumer-driven contract checks across Go, Python, Rust, and TypeScript services.

9|4|Updated May 30, 2025
One-click install
npx skills add https://github.com/Kaikei-e/Alt --skill tdd-workflow-kaikei-e
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/Kaikei-e/Alt/tree/main/.claude/skills/tdd-workflow
Command: npx skills add https://github.com/Kaikei-e/Alt --skill tdd-workflow-kaikei-e

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents regressions and runtime failures caused by service boundary changes by enforcing a test-first, contract-first development discipline that combines end-to-end, consumer-driven contract (Pact) checks, and RED-GREEN-REFACTOR unit testing. It helps teams detect proto/API contract breaks, missing required headers, and auth changes early in CI rather than in production.

Core Features & Use Cases

  • Pact CDCT / E2E First: Detects service-boundary changes and requires consumer-side Pact tests before provider changes merge.
  • Phase-driven TDD: Guides developers through Phase 0 (contract check), Phase 1 (write failing tests), Phase 2 (minimal implementation), and Phase 3 (refactor and contract regression).
  • Multi-language support: Provides language-specific test and contract commands for Go, Python, Rust, and TypeScript and prescribes locations for contract tests and provider verification.
  • Operational safety playbook: Prescriptive steps for provider-tightening changes (enumerate consumers, audit pacts/, run pact-check.sh, runtime smoke tests) to avoid large-scale outages.
  • Use Case: When adding a required header or changing a proto, use this workflow to add consumer Pact tests first, regenerate pacts, and verify providers to prevent 401/TLS cascades.

Quick Start

Use the tdd-workflow to plan a contract-first TDD run for "add X-Service-Token requirement" by creating a consumer Pact test, regenerating pacts, and running provider verification before implementing code changes.

Frequently Asked Questions about tdd-workflow

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

FAQPage Schema
How do I prevent API regressions when changing service boundaries across microservices?

To prevent API regressions when changing service boundaries, you need consumer-driven contract testing that requires consumer-side Pact tests to pass before provider changes merge, catching breaks early in CI.

What is the RED-GREEN-REFACTOR workflow for contract-first TDD?

The RED-GREEN-REFACTOR workflow for contract-first TDD is a phase-driven process: check contracts, write failing tests, implement minimal code, then refactor and run contract regression checks.

How do I add a required header to a proto without causing runtime failures?

To add a required header to a proto without runtime failures, create a consumer Pact test first, regenerate pacts, and run provider verification to detect 401 or TLS cascades before implementing code changes.

Does consumer-driven contract testing work with Go, Python, Rust, and TypeScript services?

Consumer-driven contract testing works with Go, Python, Rust, and TypeScript services by providing language-specific test commands and prescribing exact locations for contract tests and provider verification.

When should I use pact verification over standard unit testing for API changes?

You should use pact verification over standard unit testing for API changes when modifying service boundaries, tightening providers, or altering protos, ensuring consumer expectations are met before deployment.