neversight Test-driven development
Work in vertical slices: prove one observable behavior with a failing test, implement the smallest coherent change that passes it, then continue with the next behavior. Preserve the user's chosen public interface and existing test conventions.
Cycle
- Identify the next externally observable behavior and the narrowest stable test boundary.
- Write one meaningful test and run it to confirm it fails for the intended reason.
- Implement enough production code to satisfy that behavior without speculative features.
- Run the focused test, then the affected suite when the change warrants it.
- Refactor while green when doing so improves ownership, naming, or duplication.
Prefer tests that survive internal refactoring. Mock only at real process, network, time, or nondeterministic boundaries. A test that merely mirrors an implementation detail does not provide useful protection.
Read supporting guidance only when the current design needs it:
- Test design
- Mocking boundaries
- Interface design
- Deep modules
- Refactoring while green
Do not pause for approval between routine cycles when the requested behavior and interface are already clear. Ask only when a missing product or API decision would materially change the result.