tdd
Test-Driven Development
TDD is a design practice as much as a testing practice. Tests written before implementation force the interface to be designed from the caller's perspective. Painful test setup signals a design problem — too many dependencies, responsibilities, or the wrong abstraction boundary. Let the tests tell you.
Schools
Two schools differ on what constitutes a "unit" and where to draw the mock boundary.
London school (default here): A unit is a single class or function. Double all collaborators at module boundaries. Preferred for new code — drives interface design and keeps feedback fast.
Chicago school: A unit is a cluster of related objects. Wire real collaborators; only double external infrastructure (databases, HTTP, clocks). Preferred when retrofitting tests onto existing code with stable internal structure.
Both are valid. The choice determines where doubles live, not whether you test.
Red-Green-Refactor
More from felixnorden/skills
building-with-effect
Build TypeScript programs with the Effect library - type-safe error handling, dependency injection, concurrency, resource management, and composable abstractions. Use when working with Effect, Schema, or any @effect/* ecosystem package.
10planning-workflow
Guides structured software planning through reusable templates. Covers design concept authoring, implementation plan authoring with vertical slices, and agent configuration. Use when starting a new feature, designing a solution before implementation, producing a phased plan for a build agent, or when the user mentions planning, design phase, implementation plan, QRSPI, or vertical slices.
3solidity-development
Comprehensive Solidity smart contract development best practices covering security patterns, gas optimization, and professional documentation standards. Use when writing, reviewing, or auditing Solidity smart contracts, or when the user mentions EVM, Ethereum, blockchain development, smart contracts, Solidity, gas optimization, or security audits.
1