atelier-spec-testing

Guide stub-driven TDD and layer-boundary testing for software teams.

39|4|Updated Jan 11, 2026
One-click install
npx skills add https://github.com/martinffx/claude-code-atelier --skill atelier-spec-testing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: atelier-spec-testing
Source: https://github.com/martinffx/claude-code-atelier/tree/main/plugins/atelier-spec/skills/atelier-spec-testing
Command: npx skills add https://github.com/martinffx/claude-code-atelier --skill atelier-spec-testing

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Stub-driven TDD and layer boundary testing patterns help teams validate design contracts, reduce brittle tests, and improve confidence in code changes.

Core Features & Use Cases

  • Define interfaces and write tests against stubs before implementing real logic.
  • Apply boundary testing to functional core and edge layers (entity, service, router, repository, consumer).
  • Learn anti-patterns and best practices to ensure maintainable, scalable tests across teams.

Quick Start

Create a minimal stub interface for your domain, write tests against the stub, and then implement to satisfy them.

Frequently Asked Questions about atelier-spec-testing

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

FAQPage Schema
What is stub-driven testing and how does it improve layer boundaries?

Stub-driven testing is a TDD technique where you define interfaces and write tests against stubs before implementing real logic, ensuring stronger contracts between system layers and reducing brittle tests.

How do I apply boundary testing to functional core layers like entities and services?

Apply boundary testing by isolating functional core layers—entity, service, router, repository, and consumer—and validating their design contracts independently to achieve faster feedback and resilient tests.

What's the best way to start test-driven development using stubs for system architecture?

To start stub-driven TDD, create a minimal stub interface for your domain, write tests validating against that stub, and then implement the real logic to satisfy those tests.

Why does my test suite become brittle when testing across architectural boundaries?

Test suites become brittle across boundaries when contracts between system layers are weak; applying layer-boundary testing patterns and avoiding anti-patterns ensures maintainable, scalable tests.

Can I use stub-driven TDD for microservice consumer and repository layers?

Yes, stub-driven TDD applies to consumer and repository layers by validating design contracts through stubs, which improves confidence in code changes and ensures resilient tests across teams.