Life before and after unit test automation

Unit testing can be great in theory – but is actually quite burdensome in practice. Writing the same code over and over again instead of creating new functionality. Making sure to adapt a whole bunch of unit tests after each change to the system. No one wants to deal with these tasks. That is why you should not waste any more time and start automating your unit testing process. Not convinced yet? Read on to find out how automating unit testing can change your life.

In case you are still manually writing the code for your unit tests, you usually do that in an ad-hoc manner. Meaning that you get some requirements, implement them, and then write some unit tests to verify that your code does what it should do. If there is some more advanced organisational effort behind it, you might have to satisfy some level of code coverage with your tests before you are allowed to push/merge your implemented feature. However, by doing so, you usually do not care about putting these unit tests into a bigger picture, by applying design patterns or common naming strategies. Doing so would take even more time to think about your tests, which in turn means less time for implementing new, cool functionality. And anyways, they have already fulfilled their purpose to show that your code works. A good indicator for spaghetti unit tests is that if someone else looks at your code, there are a lot of questions (maintainable code should be self-explainable – because what if you are not there to explain any more). So what’s the problem here? Very soon, you will get to a state where you do not want to touch your unit tests any more, because you simply don’t understand what’s going on yourself, and finding out would take way too much time. But in that case, how can you adapt these unit tests if your requirements/implementation changes? You also cannot offload the work to someone else, because they also have no chance understanding your test cases. As a result, you start to ignore failing tests, because you are not sure whether this means that you actually found a bug, or your test is simply outdated. You even don’t want to find out, because understanding the test code would take too much of your precious time.

Another option (especially if there are no code coverage gates) could be that you don’t have unit tests at all, because you have learned from previous projects that the effort for the steps above simply outrun potential benefits. To be honest, doing no unit testing is indeed better than doing unit testing wrong (I’ve detailed this fact in the following article: Why you shouldn’t write a single unit test, before you know how to do unit testing right).

In case you are already using modern unit testing tools that allow you to automatically create test code yourself, you do not have to worry about writing maintainable code, of having to write the same lines of code over and over again. Simply define the essential information that varies from test case to test case, and the tool takes care of the rest. Some tools even provide guidance for this test case definition by supporting methods such as equivalence class partitioning or boundary value analysis (read more here: 2 methods that help you save 60 % of your effort in Unit Testing)

If a created test fails, you know what to do. As you know that your tests are up to date, the implementation has some problem. The name of the test case already helps you identify the part of the software code that caused the error. If you have to look deeper into the unit test – no problem, because the generated code sticks to common design practices that are made for perfect readability of your test code. If you have to improve some part of the software, and thus adapt unit tests that you have written some months ago, this is also no problem! Obviously, you don’t remember what you did back then. But you have a look at the code, and automatically know what is going on. Even if you have taken over the software part from a colleague, you don’t have to worry about understanding their code, because the automation tool forces you to adhere to a certain structure to write unit tests. And finally, you have a good feeling when shipping new versions of your software, because you know that you have testes sufficiently, and all your unit tests actually pass before shipment.

 

Let me know about your experiences with unit test automation, in the comments section below!