Writing tests can save you a lot of headaches. There are a lot of articles and youtube videos out there about why you should write tests. But have you ever wondered why many developers don’t write tests?
Ok, We’re not going to talk about what you’ll miss or what problems you’ll face if you don’t write tests. I think there is enough content about it out there. Instead, we will talk about the reasons why some developers do not write tests for their software, even though many admit that writing tests is a good practice.
How important is it?
Not writing tests is a serious issue. A lot of money is lost because of this issue in the software industry. Developers lose their credibility or even jobs because they didn’t write tests for the codes they delivered. There can be unsatisfied users. There can be lawsuits and legal troubles just because of a simple mistake or bug that could have been avoided by writing tests. So for sure, Not writing tests is an important issue and worth diving into to figure out why it happens.
I strongly believe if developers realize the issues not writing tests can lead to, many of the reasons that compelled them not to write tests won’t be strong enough to do that anymore. We will discuss some of the reasons behind this issue, So read on.
Not knowing the How
There are many developers that really don’t know how to write tests. They write them, But they don’t know how to write them. If you want to write flutter tests, you need to check out Flutter testing documentation. Flutter framework provides 3 ways of testing, unit test, widget test, and integration test. Each one has its pros and cons. I’d say the docs on Flutter testing are pretty good, But That doesn’t teach you how to write good tests.
Think about automated tests for a few seconds. You want to write code that tests another code’s behavior. Whether it behaves as expected or not. Let’s talk about it with a simple example. Let’s say you have a single unit (class, function, etc), and you want to make sure it works fine. You write 6 tests to cover different scenarios. Great, Now you want to make a small change in your unit, and suddenly all your tests show a syntax error. These tests are called broken tests. Now you have to go refactor the tests again. Here is the thing you need to know about how to write tests.
You need to write your code in a way so that your tests will break less often, and if they are broken, they take much less of your time to refactor them. If broken tests and refactoring them bother you, you’re probably doing something wrong.
So what is it that developers should know?
In short, when writing code, you should also think about how you should test it. It’s called writing testable code. You can try to improve the testability of your code by following the SOLID principle and writing your units as loosely coupled as possible. My suggestion to you would be to think about the testability of your software as you want to write it or Do TDD, for which you should write the test first and then implement the actual unit those unit tests are written for.
When you’re looking at testable software, it should be like a good car when you pop the hood. When you look under the hood, you see different parts connected together through wires and tubes. Even though these parts work together, they are not tightly coupled together. You can remove a part if you think there is a problem with it. Run some tests on it in isolation and find the problem and fix it. You don’t have to dismantle the whole car in order to replace a part or isolate it from other and test it. This is all possible because these parts and components are loosely coupled.
Not knowing the Why
If there are developers that don’t know how to write tests, then I would argue that there are definitely developers that don’t know why they should write them.
There are developers that truly don’t know why they should write tests. If you talk to them about writing tests, they agree and admit it is a good practice. And some of these developers even practice what they say. Yes, some developers write tests just because everyone else is doing it, and it is a good practice. And there are people that are very honest with themselves and think, if I see no reason to write tests, why should I write tests?
Not knowing why is not a good enough reason to forsake writing tests for good. While knowing why you should write that test is a must. (Well, I guess you should know why you’re doing what you’re doing in life as a general rule). But if there are many fellow developers out there doing something, you should at least figure out why they are doing that. If you figured out the reason and still don’t want to do it, that is respectable. There is a saying where I come from which says
Not Knowing isn’t a bad thing, But not asking is one
Not feeling the Why
This may sound like the above argument, but it isn’t. Sometimes developers know exactly what they should write tests, but they don’t. And it isn’t because of laziness or being irresponsible or anything. It’s just because they haven’t felt the pain of the issues it can cause. Some will feel those painful moments, like when you created a local database for your Flutter app and didn’t write tests for it, and it caused a series of annoying bugs that tortured you during the course of development. Or when you messed it up big time in your company and lost your credibility. Think about that moment when you wished you had written tests for your app. Or when you finally did write those tests, you wished you would have started writing tests sooner. The moment that made you feel the importance of WHY you should write tests.
Limitations of the framework or language
Sometimes the framework or stack we’re working with makes it hard for us to test the code we are writing in that framework/stack. In Flutter, if you’re writing unit tests and widget tests, it is very simple to do that. However, if you’re creating a plugin and you want to write tests for that, that can be somewhat challenging. If writing tests for your code is hard and challenging, it would be a compelling reason not to write those tests.
Not Knowing the When
There are projects where you want to write tests, but you don’t want to fully cover all units and scenarios. And that can be reasonable based on your software and its components and units. But there are parts of your software that, if it doesn’t behave as it is supposed to do (bug), Will cost you a lot. For example, if you’re creating a wallet feature for your user, that is when a feature needs to be fully tested both on the backend and front end. Because if bugs happen here, this is gonna cost you a lot. You may even get into legal problems.
Bad Experiences in the Past with writing tests
Sometimes in life, we have bad experiences in the past that will shape how we perceive things in our life and make decisions. Programming is not different. If in the past you didn’t know how to write tests, you probably had bad experiences with software testing. Hence in the future, you may avoid writing tests because you don’t find it helpful for your project, which will also slow you down.
Not realizing the damage it can cause
This is a very important one if you realize the damage it can cause to either the business/client or even to you. You can lose your credibility, or the business or client could lose their credibility, especially in this competitive market. Bugs, in the best-case scenario, will worsen User experience, which is still a bad thing. In worst-case scenarios, you could cause you’re company or client to lose users, money, resources, opportunities, stock shares, and so forth.
Your code is your reputation
Being lazy and irresponsible
I don’t see that I need to explain much here. If you care about the value of the code you deliver and how it may affect others and their lives or livelihood, you should write tests when needed.
Not given the opportunity
Ok, it’s not always the developers’ fault. Sometimes you’re going to work on legacy code or some software that has very low testability. Just because it was developed that way without any tests, and now in order to write tests for that software, you have to refactor and rewrite the whole thing. And sometimes, in these cases, companies, based on good/bad decisions, decide that the cost of dealing with bugs in production is less than refactoring the software. So they decide not to do anything about it. So the developers continue maintaining and developing the software without writing any tests.