Why you do not write tests?

Probably every developer will agree that testing software is important, everyone expects from third-party library or application that it will work, that it is well written and thoroughly tested, even if it’s free and you do not have to pay for it. So if everyone agrees, why so many developers don’t test their code?

The Problem

The first excuse that you will probably hear (or use yourself) is “I don’t have enough time for writing tests, we have a deadline…”. Yes, it is often true, we rarely have a lot of time to finish our tasks and user stories, but saying that you don’t have time to write tests means that they are a bonus, an additional thing to do afterward. If you treat it like that, then business people will probably pressure you to skip it or do it fast and get to the next task. A situation like that, in the best case, will result in one or two positive path tests, and maybe one negative, maybe even some exception handling path. I think that this is worse than no tests at all because it gives you a false confidence in your code.

Do not separate them

On the other hand, if you will think about tests as an integral part of your development workflow, think about them as a tool to drive your code forward, and include the time needed to write them well in your task estimations, you will have time to do them. Do not treat them like they are a separate part. When you debug a bug or write a new feature, and you spin up the whole application to check how it behaves, do you treat it like an additional part of a task? No, you do this because you want to know that it works, or how the bug occurs and why. You do this because you don’t have any other way than reading code to check what happens. But the truth is, all kinds of tests (unit, integration etc.) are the other way, and they offer much faster feedback than the whole application. Remember, you can perform hundreds of tests in a matter of seconds.

Bad code

Writing tests afterward have another negative aspect. In a situation like that, you often end up with code that is not easily testable, classes are bloated and do too much. When you start writing tests to code like that, your tests reflect your code in all the bad ways. They are bloated, they test too much, as in one test tests multiple paths, require an army of mocks and are not readable. On top of that, they often end up as maintenance hell, they are like a concrete poured all over your code to keep it in that state for all of eternity. These tests are just coverage generators, they just run your code. And don’t get me started on tests that have no assertions, assertions that make no sense or tests that are mocked so much, that they test mocks and not your production code! Tests like that exist, believe me…


Remember, tests are part of your code, not a separate task to do as a bonus. They are there to help you, to give you a feedback on your code in a fastest possible way. They protect your code and business logic from rogue developers whose mission is to break your code in the most subtle way that will take long hours to fix.

Next time, I’ll focus more on how to write good tests.

Also published on Medium.