test-target-design

Design testable code using Humble Object, four-quadrant classification, and contract-based boundaries.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/Hakkadaikon/hymme --skill test-target-design-hakkadaikon
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-target-design
Source: https://github.com/Hakkadaikon/hymme/tree/main/skills/test-target-design
Command: npx skills add https://github.com/Hakkadaikon/hymme --skill test-target-design-hakkadaikon

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code tangled with I/O, frameworks, and external dependencies resists unit testing, and teams waste effort testing trivial code while leaving complex logic uncovered. This Skill provides design norms for separating testable logic from hard-to-test shells and deciding where to concentrate testing effort. ## Core Features & Use Cases - Humble Object Pattern: Extract judgment and calculation logic from UI, database, and I/O layers into pure functions, leaving a thin delegation-only shell covered by a few integration tests. - Four-Quadrant Classification: Categorize code by domain complexity and collaborator dependencies (domain model, trivial code, controller, overly complex code) to assign different test strategies per quadrant. - Design by Contract Boundaries: Split responsibilities into preconditions and postconditions to decide which invalid inputs deserve tests and which are out of contract scope. - Use Case: When a retry loop mixes delay calculation with async I/O, extract the delay formula as a pure function, test it output-based with boundary values, and leave the shell to a single integration test. ## Quick Start Ask the AI to apply the Humble Object pattern and four-quadrant analysis to restructure a hard-to-test module and decide where to focus unit test effort.

Frequently Asked Questions about test-target-design

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

FAQPage Schema
How do I make code with database and I/O dependencies unit testable?

Apply the Humble Object pattern: extract judgment and calculation logic into pure functions that take inputs as arguments and return results, leaving only delegation in the I/O shell. Test the pure functions output-based and cover the shell with a few integration tests.

What is the Humble Object pattern in unit testing?

The Humble Object pattern separates hard-to-test layers like UI, databases, and external I/O from testable logic. The layer becomes a thin humble shell containing only delegation, while extracted pure functions receive thorough output-based unit tests.

Should I write tests for invalid inputs that violate preconditions?

No, inputs violating preconditions are outside the contract and generally should not be tested, since expecting specific behavior over-constrains the implementation. If you want to guarantee a response like returning 400 for malformed input, promote it to a postcondition and test it as a normal case.

How do I decide which code deserves the most unit test coverage?

Use the four-quadrant model based on domain complexity and collaborator dependencies. Domain models with high complexity and few dependencies get the thickest coverage, trivial code gets none, controllers get a few integration tests, and overly complex code gets split first via Humble Object.

When should I not use the Humble Object pattern?

Avoid it when the extracted function still references external state like time, randomness, globals, or I/O, since impure functions defeat the purpose. Also avoid leaving branches or calculations in the shell, which signals incomplete extraction.