unit-testing

Unit Test Design

When to Use

• Phase 6 of the full-stack workflow: after task breakdown is complete and before code development.
• When the user requests writing tests first or designing test cases.

Input

Read from the current iteration directory:

• Program design document (program-design-{id}.md) — modules, interfaces, data models
• Task breakdown document (task-breakdown-{id}.md) — organize test cases by task unit

Execution Points

1. Organize by task: Organize test cases using the task IDs from the task breakdown as units.
2. Granularity: Use "testable units" as units (functions, class methods, API endpoints, frontend logic blocks).
3. Coverage: Normal paths + boundaries (null values, upper limits, type errors) + exceptions (network failures, insufficient permissions).
4. Expectations: Each test case should specify the expected result or assertion points (return values, status codes, side effects, UI state).
5. Mock Strategy: Indicate which dependencies need to be mocked (database, external APIs, file system).
6. Coverage Target: Core business modules are recommended to be ≥80%; utility/configuration modules can be more lenient.

Output

• Use templates/test-case-template.md to produce the test case document, for "Code Development" to implement and verify according to the test cases.

Document and Status

• Output is written to docs/{current_iteration_id}/unit-testing-{unit_testing_id}.md。
• Before starting: call the history-manager skill's get-phase unit_testing and check-file to confirm whether it has been completed.
• After completion: call the history-manager skill's set-phase unit_testing {unit_testing_id} to record and advance the status.