Stephan Schmidt
Tests Are Bad For Developers
The real reason developers don't write tests
Technical managers wonder why developers don’t write tests. Tests are helpful! Why don’t they write them? The usual answer is they don’t want to write tests, or there is too much business pressure. Which is right, but doesn’t go deep enough.
As a developer for 40+ years, I could not live without tests. I think unit tests are one of the great inventions of our trade. For me they are part of developer accountability. Tests give me security, they tell me things are right. All tests running green gives me a warm feeling and makes me proud. Whenever I write more tests for existing code, I find bugs. I don’t follow TDD but write tests as soon as I have a feeling what the final code might look like. Rewriting all the tests all the time feels frustrating to many developers. But writing tests after you’ve finished coding is too late, they could not help you refactoring. It’s delicate finding the right moment to write tests for new code.
Tests give my coding a frame of reference. When I start to work, I run all the tests and I know I have a working state to start. When I finish, I run all the tests and I know I can stop.
But getting back on the topic.
With every CTO I talk, they think their test coverage is not good enough, they don’t have enough tests. So if tests are as great as I have described them, why are there too few? How comes?
Tests are bad for developers. That is why.
They can only detect bugs. Tests can only tell developers they made a mistake. There is no gain at that moment. For developers under pressure, it’s better for bugs to be found in production than during development when business pressure is high.
When found during development, developers need to write a fix; the time spent counts against “development time.” They are blamed for missed deadlines (Newspeak “Sprint and Goals”). They are asked why everything takes so long. Ironically, they are blamed for creating high-quality code. Sad, I know.
When a bug is found in production, unless there are too many, it’s often blamed on QA (let me tell you QA is not responsible for quality though, developers need to own their stuff—don’t let QA write tests!). When found in production, the bug fixing gets in the sprint with a story. When found in production, there might be bug-fixing sprints. All scheduled time. But when found with a test, the bug goes against the sprint commitment. There might be some discussion with product management needed. When found in production, this is sometime in the future when times might be happier, not now when there is so much pressure. An illusion, I know.
So what do developers do? They are not foolish. Not write tests is what they do. Or they write the most minimalistic tests, they have no interest in finding bugs during development when time pressure is high, just to satisfy management.
With tests, I can refactor my code. Without tests, your code will get worse and worse because you don’t feel confident enough to refactor. Mass scale Refactorings and Rewrites often happen to code bases that have no tests. Because they had no tests in the first place, they were not refactored continuously and got in the state they are now.
How do you get out of this? Tests need to be non-negotiable. Tests are part of being a professional engineer. More pressure, can we cut tests? No! “Code Monkey think maybe manager want to write god damned login page himself”., I digress.
No shortcuts. If you have QA engineers, instead of testing, they should review developer written tests. They can make sure tests are testing the right thing. They can help developers write better tests. They can help developers write tests in a way so that they are easy to change to changing requirements (hint: If you don’t have a custom domain library for your website/app to write tests against, e.g. user := LoginPage().Fill(email).Login(); assert(user.LoggedIn == true), you’re doing it wrong).
So if tests are bad for developers, they won’t write tests, duh. Paradox solved. There need to be tests written, no exceptions, for some time to gain the benefits and make tests good for developers. Make tests work for them and they will write more.
