🚢 Ship One Test a Day
Small, consistent progress beats big-bang automation projects. The compound effect of daily test commits.
The Big-Bang Trap
I've seen this pattern a hundred times:
"We'll add tests after we ship this feature."
"Let's do a dedicated testing sprint next quarter."
"Once we have bandwidth, we'll build out proper automation."
You know how these stories end. The testing sprint never happens. The bandwidth never appears. The feature ships, then another, then another, and suddenly you have 50,000 lines of untested code.
The Compound Effect
Here's a different approach: commit one test every working day.
Just one. It can be small. A single unit test. A regression test for a bug you fixed. A smoke test for a critical flow.
Let's do the math:
- 1 test/day × 250 working days = 250 tests per year
- Per developer
A team of 5 developers doing this ends up with 1,250 new tests in a year. Not from a heroic effort or a dedicated sprint. Just from consistency.
Make It Easy
The reason "we'll add tests later" fails is friction. Writing tests feels like extra work, so it gets deprioritized.
Lower the friction:
- Starter templates – A test skeleton developers can copy
- Clear patterns – Established conventions for where tests live and how they're structured
- Fast feedback – Tests that run in seconds, not minutes
- Small celebrations – Acknowledge test contributions in standups or PRs
One Habit
Make "one test" part of your definition of done. Not "full coverage." Not "comprehensive test plan." Just one test that didn't exist before.
The best test suites weren't built in sprints. They were built one commit at a time.