Next: part 2
This is the first post in a series about automated testing of software.
A long time ago, before I started my professional software development career, I had no experience with unit testing, or any type of automated testing. When I wrote a piece of code, I ran it manually with different inputs to verify that it worked. The blessings of a physics education, where many scientists were just fiddling around with code!
I’m sure many people did it like that back then, and many people still do nowadays.
Then, at my first job, one of my colleagues insisted that I wrote unit tests for my code. At first, I didn’t see much use of it, but because he was the senior guy and I was the newbie, I did what he said.
That was a massive step forward in my software development skills. Over the years, I gained more experience, and my respect for automated testing kept growing.
There are also other types of testing, for example component testing, UI testing, and integration testing. This series will look at these different types, hence the more generic name of automated testing.
In this series, I want to share with you the fine points of automated testing.There are many introductory posts to be found, where a function to multiply 2 numbers is defined and then unit tested. This series will go much further than that. It will be an advanced series, where you will learn how to write tests for a large system properly.
But first, let me try to whet your appetite by listing some advantages of automated testing. I have experienced all these advantages first hand.
You will find more bugs earlier.
This is a no-brainer of course. When you write tests for your code, you will find bugs. And you will find them early – long before your code is deployed.
You will prevent fixed bugs from reappearing.
When you fix a bug, it is good practice to create a test that demonstrates that the bug has been fixed. If you have such a test, and you modify your code later on, you can be confident that this bug will not reappear.
You will prevent bugs in part A when you modify part B.
This is a common, and very frustrating, occurrence. You change a part of your code, and somehow a different part of your code breaks. If you have unit tests for the other part, you will be able to detect the breakage while you are coding – and fix it immediately. This is called regression testing.
You will protect yourself against silly mistakes.
Sometimes your code looks good. And it compiles. And the server starts up. But you made a typo somewhere, maybe a + instead of a – , or 8640 seconds in a day instead of 86400. Or you forgot to include a necessary module. Having a test will find these issues before they become problems.
You can demonstrate how the code is meant to be used.
Tests can be great complements to documentation: they show how your code is meant to be used. I usually start by looking at the tests, when learning new modules or projects. They are often better at showing how the code works than the documentation.
You will refactor your code.
Often, when you are writing tests for a function, you conclude that it’s going to be a lot of work and/or difficult to test this function. The logical solution is to refactor such a function into smaller parts, to make each part easier to test.
It’s not always about function size, but about having a function that does too much. For example, a function that reads a file, parses the content, and sends an email will be hard to test. Split it into 3 parts, and testing will be much easier. The resulting code will be better as well.
Your design will improve.
This is an extension of the previous point. Sometimes you get new insights during refactoring, which leads you to improve your overall architecture.
You will deploy broken code less often.
The more tests you have, the less the risk that you deploy code that doesn’t work correctly. It is of course not a guarantee of faultless deployment, but it will certainly improve the odds.
You will have more confidence in your code.
This is the vaguest advantage, but for me personally a very strong one. When I’m working on code that has proper automated testing, it just feels better. I am more confident about making changes or expanding the code. I work faster because I’m less scared of breaking something important.
These are the reasons why almost all of the code I work on, has automated tests in some form. Both my professional and my personal code. There are some exceptions, like one-time scripts and throw-away proof of concept code (does that actually exist?). I hope this list of advantages will nudge you to writing more unit tests.