Developers Are (Not) Lazy! Why is It So Difficult to Get Programmers to Do Unit Testing
summary
Argues developers aren’t lazy but deprioritise tests under feature pressure and external demands, so testers stop enforcing hard KPIs and instead adopt behavior-driven development with shared glue code maintained by tester or developer; the project ships twice weekly with 1.5–2,000 functional tests and achieves 80–90% code coverage by using soft targets, pair work, clear expectations, and integration tests rather than punishing low unit coverage, while noting AI accelerates shipping and raises testing urgency.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 3:45Developer-tester collaboration
- 8:52Developers struggle with testing
- 13:07Motivating developers
- 19:12Improving developer-driven quality
- 25:46Testers learning to code
- 31:54Autonomy versus quality
- 35:52Team responsibility for quality
- 40:33Progress tracking without coverage
- 44:50Unified team approach
related talks
37mThe Lazy Tester
58mDeveloper Joy – How Great Teams Get S%*t Done
48mTesting is Confidence - A Developer's Perspective
21mDevelopers vs Quality Assurance
12mThe Lazy Tester: Musings On Being Efficient
23mWhy testing is also a developer's problem
42mUse testing to Develop Better Software Faster
36mHow programmers & testers can be productive