You have a well- established, stable development team. They are veterans and quite experienced. You feel there’s nothing they can’t solve or achieve, even if it takes some time, they’ll manage, whether if it’s a bug or a feature.
Ok, then why would you look for troubles where there aren’t any? You are already late with some deadlines and there are a lot of bugs on the table that needs to be taken care of.
Additionally, everything works even when it is not so smooth – the company is profitable, the customers are quite satisfied. Why not keep the status quo and take a risk for something you don’t know what the result will be like? On top of that, you have a senior team with their own work routine, a career that was built over the years with quite a lot of experience. Maybe some of them are even considered to be “Old school”. Still, we ask, why should one adapt unit tests anyway?
I’ll start with a fact that is known to us as programmers. To be a programmer, it is not enough to only graduate computer science/ software engineering B.Sc. The job demands us to keep studying most of the time – or at least very often. Hence, being “Old School” doesn’t really exist in this field.
Technology always changes so does our job requirements. So, regarding these senior developers, you were concerned to approach to, announcing the change you would like to adapt to the company: do not worry. They are used to changes and acclimation if they are really seniors.
It might create a little “noise” but eventually, it will be accepted as a lot of things in our lives. You (and probably they) know that the Company’s best interest should be always on top, otherwise, why are we there?
Now, to the serious part: Why do you really need your team to do unit testing?
Think of it as a gym. You start to work out at the gym because you know it’s healthy and worthwhile in general, especially in the long run, from all aspects. There is an infinite number of researches about it so I don’t need to evaluate it.
So you started working out now… it is not fun, sometimes not at all at the beginning. Before you go to work you have to arrange your sports bag: towel, water bottle, workout clothes, shoes. After a long and exhausting day at work, you got to run to the gym, follow your program and sweat a lot instead of relaxing at home.
An additional fact is that you are probably going to wake up sore the next morning and the upcoming days. What is this all for? You already know the answer.
The beginning might be a little difficult but after a while, you get used to it, or partly used to it. You are not sore anymore. Your new routine is healthier for you and makes you feel better. The benefits of exercising outweigh the rest. The same applies to unit testing.
The product is functioning well, you have satisfied customers but you can do better. How?
Let’s start with what mostly triggers senior management: money. Or saving money, to be exact. Unit tests save the company a lot of money, and money means more manpower, promotion, everything.
In the business world, there are a lot of processes in which the ROI takes some time. Unit testing is one of those processes. There’s a good chance you won’t see it in the short run and it might even cost you more (adapting to unit tests) but the more time goes by the more the company will benefit and that’s due to the fast feedback idea.
Programmers are now able to find the bugs already in the development process. Finding the bug alone is already a life-changer because sometimes it can be very difficult and costly too.
Once a bug is inserted, the more we move in the development chain finding a bug and fixing it is increasing in an exponential curve.
With unit tests, your developers have much more confidence to change the code in the second year of the project as much as they did in the first month, the first year of the project.
Without Unit tests, the more the time goes by the more our code gets older and older and becomes what we call “legacy code”.
Programmers are sometimes so afraid to touch the code that they refuse to change anything and prefer to write from the beginning which is an absolute waste of means. You already know what means refers to.
Another reason that stands for unit tests being frugality: when we write good tests, we are basically providing another source of documentation to our code.
Every Unit test describes what it is doing and what it is supposed to return. When a new programmer is recruited to the company or an existing programmer that merges to a new project sees the code for the first time, it is probably going to be easier to adapt when you have such a good additional explanation of it, as unit tests provide.
Faster adaption means that the tasks are going to be done faster compared to what they would have probably been if there were no unit tests (I use the word compared to since every programmer has it is own pace).
A lot has been spoken about unit tests and many of the serious companies in the market understand the great benefits of them. These companies managed to integrate unit tests into their workspace and broke the status quo bravely. They probably had a good reason to.
Don’t fear change, embrace it!
Your team can unit test without changing the code, even legacy code. How?
With Isolator for .NET Or Isolator for C++.
