How We Made Unit Testing Part of Our Engineering Culture
Article Summary
Instawork runs over 1 million tests daily in their CI pipeline. Here's how they made unit testing a core engineering practice, not an afterthought.
Duncan Edwards from Instawork's engineering team shares their journey building a robust testing culture. They've grown to 30,000+ Python unit tests with strategies that go beyond just measuring coverage.
Key Takeaways
- Sonarcloud decorates every PR with coverage metrics for new and modified code
- Special CI job runs tests at dangerous times: New Year's, daylight savings changeovers
- Factory Boy with LazyAttribute prevents time-freezing issues in test factories
- GitHub Copilot generates initial test implementations from meaningful test names
- Pytest-xdist enables parallel test execution with database isolation per thread
Instawork combines cultural commitment with automated tooling (coverage tracking, time-based flakiness detection, AI assistance) to maintain high-quality unit tests at scale.
About This Article
Tests kept failing on specific dates like New Year's and daylight savings changeovers, even though the code was fine. These flaky tests were slowing down development because it was hard to tell if failures meant real bugs or just bad timing.
Duncan Edwards' team created a CI job that runs new and modified tests at four specific times: December 31 at midnight, January 1 at 6am, the day before daylight savings at noon, and the day of changeover at 6pm. They used freezegun's tick parameter to let time move forward during tests.
The approach reduced flakiness in Instawork's test suite. The team now runs it on-demand instead of in standard CI because it costs too much to run multiple test reruns per PR.