IT IS BORING TO TEST!

We’re developers. We want to be creative, we want to solve problems. That’s what we live for. But let’s face it, testing is the opposite of coding. It is just a big repetitive task. It is tedious. Unfulfilling. It. Is. Boring!

Sure, you run the code that you are working on. Even single step it and verify that it works. But do you ever think of the rest of the code? What if you just move the counter in here, except that you forgot that it should be increased in that other leg of the if too. Or what about that other class that calls this one, that relies on how it used to work. It expects this class to do what it did before, and now it doesn’t. Did you test that? Did you even remember that it had a dependency on your code? That means that for every change you do, you basically have to identify every place that the code affects, no matter how many levels up, or even sideways, and test that too. Every time. And do you verify the code with all the different user rolls that the system handles? Admin should be allowed to do stuff that a regular user doesn’t.

Do you really do that?

Didn’t think so.

So what’s a good alternative?

In this article I will talk about one alternative, unit testing. But why is that such a good alternative?

TO START with, you can be lazy. You write a test once and then let the computers do the work for you. It is actually also a time saver. No matter how fast you are at executing the code by hand, the computer will be faster. In the same time that you verify the code you are working on, it will have tested the entire code base, with all dependencies that it has on your code.

AND YOU can continue to be lazy. Unit tests tells you where the bug is. You don’t have to spend time to track it down. A unit test shows exactly what behaviour that didn’t do what it was expected to do. So once again, the computer does the work for you.

IT IS less boring to wait for a computer to finish testing than it is to manually do the same test over and over and over again. Manual testing is done by humans, and humans tend to be sloppy when doing repetitive tasks, which means that the quality of what you deliver will also be sloppy.

If you instead let the computer do the testing, it will do the exact same thing with full attention every time. That’s what computers are good at. Repeating stuff. Make use of it.

SPEAKING OF boring. How often do you test everything from top to bottom manually? Once every blue moon is my guess. Seriously, many times you try to do it maybe once every major release or when you know that you have changed much.

But if you let the computer do it, you will test everything every time you run the tests. And that is, if you have set up your system correct, at a minimum every time you check in your code. Probably even more often than so if you also run tests locally on your workstation.

DO YOU want to know that there a new bug in the code when you are writing it and have it fresh in your head, or a month later when you have forgotten all about it and have to interrupt what you are working with now?

If you are told that your code does something wrong at the time you are coding it, then I bet you think that is a good thing. You are in the process of doing it the best you can, so why not include bug fixes? But if you have to interrupt what you are doing and return to the old code, it disturbs you. It is a negative thing. It interrupts your focus. And task switching takes time.

Unit tests are immediate (more or less). You get the information you need when you need it and can act on it.

I MENTIONED saving time earlier. By letting the computer do the work for you, you can stop doing testing and code instead. Focus on the good stuff.

WHICH LEADS me to the next point. Writing tests is coding. It is using your skills. It is solving problems. Manual testing is the opposite. It is pushing buttons and clicking buttons.

THERE IS a cool side effect to writing tests too. It automatically documents the code. All you have to do is to minimize your test functions so you only see the function names, and voila, a list with everything the function does and the outcome of it doing so.

Example: The function that gets the customer from the database should return an empty list if it can’t find the requested name.

public void GetCustomer_TheRequestedNameIsNotInTheDatabase_ReturnsEmptyList()

AND THERE’S more to the self-documenting code. Let’s say that you download a new library from the Internet. It has a document which describes all the ins and outs of the code. And at the end of it is all the code examples. Where do you look first? The code examples of course! You’re not going to waste time on reading when you can start coding.

When you write unit test, you actually write code examples for your code. So, not only do you have an index of all expected behaviour, you also have code examples for all of them.

And you didn’t have to spend one minute on writing documentation. Talk about getting money for nothing.

NOW TO a real benefit! You have finished this class. And you look at the code and think that you could do it better. You want to refactor it. But there is that nagging suspicion that you will break something. As they say: “Don’t fix it if it isn’t broken.”

But now you know that someone’s got your back. You have unit tests. The tests will tell you if the code stops doing what it’s supposed to do. They will immediately point you to what you broke.

This has the effect that you dare change the code. Unit tests gives you confidence. They will enable you to make the code more readable, less cluttered, easier to debug and so on. In short, there is nothing that stops you from refining the code and make it the best code you’ve written.

This is actually a more profound mental change than you think at first. Trust me. You will come to a point where you will notice that you don’t think of the danger of changing the code. And that is a liberating feeling.

There’s another profound change in how you code, that you will notice. To make code as easy to test as possible, who likes to make things harder for themselves, you restructure the code. It will be clearer, shorter, simpler… It will start following the SOLID principles. For instance, it is much easier to test something that only does one thing than something complex. So the next time you read the code, you will spend a shorter time decoding what it does. You will figure out faster what you have to change. You can see where the bug is by just a glance. You. Will. Save. Time.
Come on, dare to be lazy.

IF YOU are brave enough to practice Test Driven Development, you will also start thinking of what the code is supposed to do before you actually write it. It’s like measuring twice and cutting once. You start doing the right thing from the beginning.

WHEN YOU write the code, the cost will be on the development account. You can charge the customer for the time spent. But as soon as you have delivered the code and you need to correct a bug, it’s your fault, and the cost is on your account.
By writing tests and finding the bugs immediately, you can make money instead of spending money when you hunt bugs. Not to count the time you lose when you have to stop making money on other projects because the bug has to be fixed right now.

Conclusion

All this boils down to two things.

The code you deliver is well tested and relatively bug free. You have confidence that you have done what you can to deliver quality.
The customer will appreciate that you deliver good stuff and start trusting you. That in itself could mean that you may get more deals with them. Or at least, they will not cringe every time you deliver a new version because they know it will work.

And you spend far less time on reading unreadable code and hunting bugs. Instead you spend it on writing code that makes money. And that is what pays both your next raise and your bosses.

— Cheers!!