Categories
Extreme Programming Fit for Purpose Kanban Programming

Making Unit Tests Part of the Work, Not a Separate Task.

Most delivery slowdowns start with a simple, well-intended mistake: we break a user story into “coding” and a separate “unit-test” card so we can estimate them individually. On paper, the board looks tidy; in reality, we’ve planted a fault line between behaviour and validation. The “real” work gets finished first, tests slip to the end of the sprint, and when the schedule tightens, they’re the first to be cut. The result is familiar regressions sneak past reviews, bugs balloon in production, and the backlog fills with technical debt that costs more to fix than it ever saved. Sandro Mancuso calls this out bluntly in The Software Craftsman: Unit tests are not second-class citizens, they are the work.

The lesson is clear: tests are not overhead; they’re the executable specification of the feature. When we treat them as optional, we signal that verifying behaviour is less valuable than writing code. Yet, the tests protect the code from rot, document intent for future maintainers, and enable fearless refactoring. Folding test design into the development task forces us to define clear acceptance criteria up front and shortens the feedback loop dramatically. The code becomes easier to reason about, defects surface within minutes instead of days, and the team builds a shared language around what “done” truly means.

As a Staff Engineer, you have the leverage to embed this mindset at scale. Start by rewriting the Definition of Done to include a “red→green→refactor” cycle: no card is ready for review until it comes with unit tests that fail without the implementation and pass with it. Pair with product owners to slice stories thin enough that each delivers measurable behaviour and its corresponding test in a single pull request. Refactor the CI pipeline to reject code without tests or with dropping coverage in changed areas. Finally, mentor through practice runs 15-minute TDD katas daily and shadow less-experienced engineers during their first “test-first” tasks, reinforcing that quality is created and not inspected.

The payoff compounds quickly. Releases stabilize because every change is guarded by its proof. New engineers ramp faster because the tests explain intent better than documentation. Leadership sees predictability rise as rework falls, unlocking capacity for innovation instead of bug-fix sprints. By refusing to outsource quality to a separate column on the board, you transform testing from a line item into the heartbeat of professional software craftsmanship.