Menü
Unit test writing and execution with coverage threshold enforcement
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Test failure diagnosis, source code fixes, and regression detection
Environment verification, dependency installation, baseline test verification
Contract-first single-task implementation dispatched by Coder Coordinator
Integration test writing for component boundaries and external dependencies
API reference documentation skill. Produces and updates API endpoint documentation from contract files in .sdd/docs/api-reference.md.
Architecture documentation skill. Produces and updates architecture overview, component diagrams, technology stack, design decisions, and directory structure in .sdd/docs/architecture.md.
| name | code-unit-tests |
| description | Unit test writing and execution with coverage threshold enforcement |
| argument-hint | Invoked by Coder Coordinator - do not call directly |
Phase: 3 (Unit Tests) Common contract:
.github/skills/CODER-SKILL-CONTRACT.mdSpec refs: FR-027, FR-028, FR-029, FR-030
This skill is dispatched by the Coder Coordinator during Phase 3. It reads spec acceptance scenarios, writes BDD-derived unit tests covering happy paths, error paths, and edge cases, runs them with coverage enforcement, and reports results to the coordinator.
| # | Input | Description |
|---|---|---|
| 1 | skill_path | Path to this SKILL.md file |
| 2 | wp_path | Path to the WP file being implemented |
| 3 | contracts_dir | Path to contract files for this WP (.sdd/plans/contracts/<WP-slug>/) |
| 4 | spec_path | Path to the source spec file |
| 5 | patterns | Active code-domain patterns to avoid (from code-patterns.md) |
| 6 | target_language | Programming language (e.g., TypeScript, Python) |
| 7 | target_framework | Framework (e.g., Express, FastAPI, React) |
| 8 | task_list | Tasks with acceptance criteria and spec refs |
Report to the coordinator with these fields:
| Field | Type | Constraints | Description |
|---|---|---|---|
status | enum | success or failure | Skill outcome |
files_modified | list(string) | file paths | Files created or changed |
tasks_completed | list(string) | T-XX format | Tasks finished |
test_results | object | pass_count, fail_count, coverage_pct | Test run summary |
issues | list(string) | free text | Problems encountered |
failure_reason | string | nullable | Why the skill failed (if status is failure) |
The test_results object SHALL include:
pass_count: Number of tests that passedfail_count: Number of tests that failedcoverage_pct: Code coverage percentage achievedThe coordinator uses test_results.fail_count to decide whether to dispatch the debug skill (FR-010). This field MUST be present and accurate.
Tests SHALL be derived from spec acceptance scenarios using a BDD approach. Do NOT derive tests from reading the implementation source code.
For each task in the task_list:
For each acceptance scenario, create test cases following this mapping:
| Scenario Type | Test Cases to Create |
|---|---|
| Happy path (normal flow) | 1 test per success scenario |
| Error path (validation failure, missing data) | 1 test per error condition |
| Edge case (boundary values, empty inputs) | 1 test per boundary |
| Precondition violation | 1 test per precondition |
| Postcondition verification | 1 test verifying output shape/content |
Each test SHALL follow the Arrange/Act/Assert pattern (equivalent to Given/When/Then):
# Given: Set up preconditions and inputs
# When: Execute the action under test
# Then: Assert expected outcomes
Name tests descriptively so the test name reads as a behavior specification:
test_create_user_returns_user_with_hashed_passwordtest_create_user_rejects_duplicate_email_with_USR_001test_create_user_1test_it_worksFor each task, write tests covering ALL three paths:
Do NOT skip error paths or edge cases. If the spec mentions an error condition, there SHALL be a test for it.
Tests SHALL test real behavior through real code paths:
Example of real behavior testing:
# GOOD: Tests real behavior
def test_create_user_hashes_password():
result = create_user(CreateUserInput(email="a@b.com", password="secret"))
assert result.password_hash != "secret"
assert verify_password("secret", result.password_hash)
Mock ONLY external dependencies -- never the subject under test:
What to mock (external dependencies):
What NOT to mock (subject under test):
Mock boundary rule: If it crosses a network, process, or I/O boundary, mock it. If it is in-process computation, do NOT mock it.
Use the project's existing test framework. Detect from the project configuration:
| Language | Framework Detection | Default |
|---|---|---|
| Python | pytest in requirements/pyproject.toml | pytest |
| TypeScript/JavaScript | jest or mocha in package.json | Jest |
| Go | Built-in testing package | testing |
| Rust | Built-in #[cfg(test)] | built-in |
Follow the framework's conventions for:
test_*.py, *.test.ts, *_test.go)tests/, __tests__/, alongside source)assert, expect, require)Every test SHALL be capable of failing. Apply these constraints before finalizing any test file.
The following assertion patterns are FORBIDDEN:
# FORBIDDEN -- Python
assert True
assert 1 == 1
assert "hello" == "hello" # literal-to-literal comparison
self.assertTrue(True)
// FORBIDDEN -- TypeScript/JavaScript
expect(true).toBe(true);
expect(1).toEqual(1);
assert.ok(true);
// FORBIDDEN -- Go
if true != true { t.Fatal() }
A valid assertion MUST compare a computed value against an expected value:
# VALID -- compares computed result to expected
assert create_user(input).email == "a@b.com"
The following patterns are FORBIDDEN:
# FORBIDDEN -- Python
def test_something():
pass
def test_something():
... # Ellipsis as placeholder
def test_something():
"""TODO: implement"""
// FORBIDDEN -- TypeScript/JavaScript
it('should do something', () => {});
it('should do something', () => { /* TODO */ });
test('placeholder', () => undefined);
Every test body SHALL contain at least one assertion that exercises the subject under test.
Tests that ONLY verify a mock was called, without verifying behavior, are FORBIDDEN:
# FORBIDDEN -- only checks mock was called, not what happened
def test_create_user(mock_db):
create_user(input)
mock_db.save.assert_called_once()
# No assertion on the return value or side effects
# VALID -- checks mock interaction AND verifies behavior
def test_create_user_saves_and_returns(mock_db):
mock_db.save.return_value = User(id="123", email="a@b.com")
result = create_user(input)
mock_db.save.assert_called_once_with(expected_user)
assert result.id == "123" # Verifies actual behavior
assert result.email == "a@b.com"
Exception: assert mock.called is acceptable ONLY when verifying a required side effect (e.g., "the system SHALL send a notification email"). In this case, the mock assertion IS the behavioral test. But the test SHALL also verify the arguments passed to the mock.
Before adding any test, apply this mental check:
Place test files according to the project's existing convention. If no convention exists:
| Language | Convention |
|---|---|
| Python | tests/unit/test_<module>.py |
| TypeScript | tests/unit/<module>.test.ts or src/__tests__/<module>.test.ts |
| Go | <module>_test.go (same directory as source) |
| Rust | #[cfg(test)] mod tests in source file, or tests/ for integration |
Group tests logically:
describe() blockst.Run() subtestsAfter writing all unit tests, run the complete test suite. Use #tool:execute/executionSubagent to run test commands -- it filters output to relevant portions (failures, coverage summary) and preserves context budget.
Execute tests with coverage enabled:
| Language | Command |
|---|---|
| Python | pytest --cov --cov-branch --cov-report=term-missing |
| TypeScript (Jest) | npx jest --coverage |
| Go | go test -coverprofile=coverage.out -covermode=atomic ./... |
| Rust | cargo tarpaulin |
Record the following from the test output:
pass_count)fail_count)Include test results in the output contract:
test_results:
pass_count: <number>
fail_count: <number>
coverage_pct: <number>
If any tests fail:
fail_count to the exact number of failing testsissuesfail_count > 0 to trigger debug skill dispatchBefore verifying coverage, read the minimum thresholds from the WP file's YAML frontmatter:
coverage_code from WP frontmatter. If the field is absent, use the default: 80.coverage_branch from WP frontmatter. If the field is absent, use the default: 90.coverage_branch).After running tests, verify coverage meets the WP-specific minimum thresholds determined in Step 6a:
| Metric | Minimum Threshold |
|---|---|
| Code coverage (line/statement) | coverage_code from WP frontmatter (default 80%) |
| Branch coverage | coverage_branch from WP frontmatter (default 90%) |
If coverage is below either threshold:
if/else branchesswitch/match casestry/catch, except, if err != nil)If after 3 iterations of adding tests the coverage still does not meet thresholds:
status: success (the tests themselves pass -- coverage is a coordinator concern)issuesIf coverage meets or exceeds both thresholds on the first run:
status: successDo NOT read the implementation source code to decide what to test. Tests SHALL be derived from:
This prevents tests that merely confirm what the code does rather than what is should do.
Do NOT perform quality assessment, review checklists, or "verified implementation quality" statements. Write tests, run them, report results. The Reviewer is the sole quality gate.
Contract files in .sdd/plans/contracts/ are READ-ONLY. Do NOT modify any contract file. If a contract appears incorrect, flag it as an issue and continue.
If existing tests from a prior phase fail:
test_results