test

Write failing tests against stub implementations to define executable specifications.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/sofer/.agents --skill test-sofer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test
Source: https://github.com/sofer/.agents/tree/main/skills/test
Command: npx skills add https://github.com/sofer/.agents --skill test-sofer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Tests define expected behaviour before implementation by driving stub development in the red phase of TDD.

Core Features & Use Cases

  • Write unit tests against stub implementations to validate interfaces
  • Use stubs to define expected behaviours before coding the real logic
  • Drive regression safety by keeping a runnable spec of the system

Quick Start

Write tests that fail due to NotImplementedError and then implement the stubs to satisfy them.

Frequently Asked Questions about test

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

FAQPage Schema
How do I write unit tests against stub implementations in TDD?

To write unit tests against stub implementations in TDD, you define executable specifications by creating tests that fail in the red phase due to NotImplementedError, then implement the stubs to satisfy the expected behaviors and drive regression safety.

What is the red phase in test-driven development?

The red phase in test-driven development is the initial stage where you write executable specifications that fail because the target logic is unimplemented. Stubs raise NotImplementedError to validate interfaces and define expected behaviors before coding the real logic.

Can I use stubs to define expected behaviors for integration tests?

Yes, you can use stubs to define expected behaviors for integration tests. This approach applies to both unit and integration boundaries to drive design and ensure regression safety by keeping a runnable spec of the system before coding the real logic.

What's the best way to structure tests around stubs that raise NotImplementedError?

The best way to structure tests around stubs that raise NotImplementedError is to write tests that define expected interfaces and behaviors first. This drives stub development in the red phase, providing patterns and examples to ensure regression safety.

Why do my test-driven development stubs fail during the red phase?

Test-driven development stubs fail during the red phase because they are intentionally unimplemented, raising NotImplementedError. This validates interfaces and defines expected behaviours before coding the real logic, ensuring the tests act as a runnable spec.