Code & Test Health exit conditions
Candidate exit conditions for the Code & Test Health type. See the catalog overview for how to adopt these.
Test coverage
| Exit condition | What it checks |
|---|---|
|
Overall line coverage meets or exceeds the configured minimum threshold. |
|
Overall branch/decision coverage meets or exceeds the configured minimum threshold. |
|
Lines added or changed in the diff meet the required line-coverage percentage. |
|
Branches introduced or modified in the diff meet the required branch-coverage percentage. |
|
Total coverage does not drop below the previous baseline for the branch. |
|
Modules tagged as business-critical meet a stricter per-module coverage floor. |
|
The absolute count of uncovered executable lines stays under the configured cap. |
|
Every source module individually clears its minimum coverage threshold. |
|
Newly introduced public methods each have at least one exercising test. |
Test pyramid and suite balance
| Exit condition | What it checks |
|---|---|
|
Unit tests make up at least the required share of the total test count. |
|
Integration tests fall within the configured proportional band of the suite. |
|
End-to-end tests stay below the configured maximum share of the suite. |
|
Each public domain class has at least one dedicated unit test class. |
|
Every exposed HTTP endpoint has at least one integration test. |
|
Each critical user journey is covered by at least one end-to-end test. |
|
Slow high-level tests do not outnumber fast unit tests. |
|
Test count grows proportionally with added production code in the diff. |
Test reliability and determinism
| Exit condition | What it checks |
|---|---|
|
No test in the suite is marked or detected as flaky. |
|
No tests remain in a quarantined or skipped state without waiver. |
|
Any quarantined test carries an unexpired remediation deadline. |
|
Repeated runs of the suite produce identical pass/fail results. |
|
Tests do not depend on real wall-clock time or |
|
Any randomness used in tests is explicitly seeded for reproducibility. |
|
Each test sets up and tears down its own state without leaking to others. |
|
Tests pass regardless of execution order or shuffling. |
|
Tests make no calls to live external network services. |
|
Every test releases resources and leaves no residual files or connections. |
Test quality and assertions
| Exit condition | What it checks |
|---|---|
|
Every test method contains at least one assertion. |
|
Tests avoid tautological assertions such as |
|
Tests meet the minimum ratio of assertions to executed statements. |
|
No assertions are commented out or conditionally disabled. |
|
The mutation-testing kill score meets the configured minimum. |
|
No mutants survive in modules tagged business-critical. |
|
Designated invariant-heavy logic has property-based test coverage. |
|
Each consumed external API has a consumer-side contract test. |
|
Each provided API verifies published consumer contracts. |
|
New behavior lands with its test in the same or an earlier commit. |
|
Snapshot/golden files are regenerated and match current output. |
Test speed, fixtures, and mocks
| Exit condition | What it checks |
|---|---|
|
The full test suite completes within the configured time budget. |
|
Each individual unit test runs under its per-test time limit. |
|
Tests exceeding the fast threshold are explicitly tagged as slow. |
|
Tests are safe to execute in parallel without shared-state contention. |
|
Fixtures expose no shared mutable state across test cases. |
|
Configured mock expectations are actually verified, not merely stubbed. |
|
Mock count per test stays under the configured limit to avoid brittle tests. |
|
Complex test data is constructed via builders rather than ad-hoc literals. |
|
Tests reference no production credentials, hosts, or secrets. |
Akka test harness conventions
| Exit condition | What it checks |
|---|---|
|
Each Event Sourced Entity has a unit test using |
|
Each Key Value Entity has a unit test using its |
|
Each Workflow has a test exercising its steps via the Workflow |
|
Integration tests extend |
|
Endpoint integration tests drive requests through the provided |
|
Agent tests use |
|
View tests use |
|
Each Consumer has a test verifying its handling of consumed events. |
|
Each Timed Action has a test verifying its scheduled invocation behavior. |
Code complexity and size
| Exit condition | What it checks |
|---|---|
|
No method exceeds the configured cyclomatic-complexity budget. |
|
No method exceeds the configured cognitive-complexity budget. |
|
No source file exceeds the 500-line Rule of 500 limit. |
|
No function or method exceeds the configured line-length limit. |
|
No function signature exceeds the configured parameter-count limit. |
|
Block nesting depth stays within the configured maximum. |
|
No class exceeds the configured line-count limit. |
|
Halstead effort per method stays under the configured ceiling. |
|
No class exceeds the configured number of methods. |
Duplication and dead code
| Exit condition | What it checks |
|---|---|
|
Duplicated-code percentage stays under the configured threshold. |
|
No duplicated block exceeds the configured minimum token length. |
|
Static analysis reports no unreachable or unused production code. |
|
The codebase contains no unused imports. |
|
The codebase contains no unused local variables or fields. |
|
No statements are provably unreachable. |
|
No private methods or fields are left unreferenced. |
|
No blocks of commented-out source code remain. |
Static analysis, lint, and type safety
| Exit condition | What it checks |
|---|---|
|
The linter reports zero violations at or above the configured severity. |
|
All files conform to the project’s automated formatter output. |
|
Compilation produces no warnings under the project’s warning settings. |
|
No unjustified warning-suppression annotations are present. |
|
No raw generic types are used where parameterization is required. |
|
No unchecked or unsafe type casts remain in the code. |
|
Public API surfaces carry explicit nullability annotations. |
|
Unnamed numeric literals are replaced by named constants. |
|
Identifiers conform to the project’s naming-convention rules. |
|
Static analysis reports zero critical- or blocker-severity findings. |
Architecture, maintainability, and error handling
| Exit condition | What it checks |
|---|---|
|
Dependencies flow only in the permitted direction across architectural layers. |
|
No circular dependencies exist between packages or modules. |
|
Efferent/afferent coupling per module stays within the configured budget. |
|
Class cohesion (LCOM) meets the configured minimum. |
|
The maintainability index meets or exceeds the configured floor. |
|
All checked error and failure paths are explicitly handled. |
|
No caught exception is silently ignored without logging or rethrow. |
|
No overly broad catch of generic exception types without justification. |
|
Every public type and method carries documentation comments. |