levels

Guides unit and integration test design with coverage criteria and step-by-step procedures.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Choosing what to verify at the unit level versus the integration level is a common source of test suite bloat and gaps: logic branches leak into slow integration tests, or connection mismatches (SQL dialects, serialization, transaction boundaries) go untested. This Skill defines clear coverage criteria and execution procedures for both levels inside a single service. ## Core Features & Use Cases - Unit Test Guidance: Enumerate public behaviors, assign black-box techniques (equivalence partitioning, boundary values, decision tables), drive cases via TDD Red-Green cycles, and confirm completion with C1 branch coverage and MC-DC for safety-critical conditions. - Integration Test Guidance: Enumerate connection paths as a boundary-by-operation table, assign one representative success and failure case per boundary, and verify against real engines (e.g., Testcontainers) instead of in-memory substitutes. - Use Case: When building a repository layer over a real database, use the integration procedure to fix the exact number of tests needed (boundaries x representative cases) and detect shared-state pollution by running tests with shuffled ordering. ## Quick Start Ask the AI to apply the levels skill to design unit and integration tests for a specific module, listing its public behaviors and external dependency boundaries first.

Frequently Asked Questions about levels

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

FAQPage Schema
How do I decide between unit tests and integration tests?

Use unit tests to exhaustively cover logic branches, boundaries, and exceptions of an isolated unit with dependencies cut off. Use integration tests to catch connection mismatches across module and dependency boundaries, such as SQL dialects, serialization, and transaction scope.

How many integration test cases do I need per boundary?

Assign one success path and one business-meaningful failure path per boundary. For symmetric read/write boundaries, a single round-trip case covers both directions, keeping the total count fixed at boundaries times representative cases.

When is unit test coverage considered complete?

Coverage is complete when every equivalence class and boundary has a representative case, C1 branch coverage shows no unreached branches, and safety-critical compound conditions satisfy MC-DC with cases where each condition independently changes the outcome.

Should integration tests use in-memory databases or real engines?

Use real engines such as Testcontainers-managed databases for important paths, because in-memory substitutes can miss production dialect differences. Reserve in-memory substitutes only for boundaries where dialect differences cannot appear.

Why do my integration tests fail depending on execution order?

Order-dependent failures indicate shared-state pollution, typically from reusing a database across tests without cleanup. Detect this by running tests with shuffled ordering and isolate state per test to restore independence.