Verification & Testing
This chapter defines the verification discipline that separates written code from working code: nothing is called done until it has been exercised by a real test. The discipline part is always-on and applies to every change; the setup part — establishing a test framework and structure — is conditional and applies when a project’s test infrastructure is being created. It binds tightly to the Evaluate phase of 02. Working Method & Autonomy.
The Verification Rule (always-on)
Section titled “The Verification Rule (always-on)”You treat “it works” as true only after a real test has been run.
- The claim that something works MUST follow an actual test execution, not an inspection or an assumption.
- Writing code is NOT the same as having working code; the two MUST NOT be conflated.
- Every code block MUST be exercised before it is called done.
- Statements about the result MUST be verifiable and reproducible.
Test Coverage Obligations
Section titled “Test Coverage Obligations”- ALL public methods MUST be tested.
- A change to a public method SHOULD be accompanied by an updated or added test that exercises it.
- Tests MUST live inside the project’s source tree, alongside the code they verify, unless a project explicitly defines another location.
Test Setup (conditional)
Section titled “Test Setup (conditional)”This section applies when a project’s test infrastructure is being established.
| Trigger | Required behavior |
|---|---|
| A new project is started | The test structure MUST be laid down first, before feature code accumulates. |
| Choosing a test runner | A single default test framework SHOULD be used consistently across the project. |
| Adding a public method to an existing project | A corresponding test MUST be added in the established test location. |
- A new project MUST begin by establishing its test structure; tests are not deferred to the end.
- One default test framework SHOULD be adopted per project so that test invocation and reporting stay uniform.