When I realized the importance of Testing
During college, you’re hardly taught about testing as much and almost never about the importance of testing. You write code which only you understand and never really bother to test it out. Well, to be honest, it isn’t your fault because either only you or around a group of 4 write all the code in the project, ensure it’s working, push it (I never did this too) and then forget about it.
You finish college and join a corporate. Suddenly you realise the existence of this concept called testing and how you have to test every piece of production code you write. Unit tests, Integration tests, UI tests, System tests and a hundred more types: You just don’t understand all the fuss and can’t get your head around it.
Especially in an agile-driven company, testing is given equal importance to production code!! Most of the times, you’ll have to write a test before writing production code(TDD). You feel testing slows you down and you would rather write another thousand lines of code which bring in all the new features your client/manager ever wanted. It’s frustrating, isn’t it? Well, same :))
A software company’s cost on a project usually varies like this:
Cost is almost directly correlated to the hours spent by the employees and therefore we can derive that around 67% of the effort goes into maintaining and fixing old software. This is where testing becomes significant enough. The company does not want you to be the only one to understand the code you write because, in all likelihood, someone else will need to maintain your code later in time. The tests help in this case. It also serves as documentation (Read further to know why).
Recently, when I was working on a legacy system, I wanted to fix a bug in a function that failed for a few edge cases. Now, because I hadn’t written all the code myself, I did not know what else would break even if I changed a single line of that function. I did not have the confidence to just change that piece of code without being sure that the rest of the system would function the way it would. This is where I learnt my lesson of writing good tests. If there were good tests covering every possible scenario that the function covers when even a single line change will reflect what will break.
Tests give you confidence to change code
If you’re still a little sceptical, let’s consider a simple code block:
for (int i = 0; i ≤ 10; i++) {
list.append(i);
//do something
}return list;
Assume I don’t have a test for this piece of code because I feel that what this code does is pretty obvious.
5 years down the lane, this code is identified to have a bug and is supposed to be fixed by someone else. The ‘equal to’ in i ≤ 10 is not obvious anymore to this new person who’s fixing your code. They believe this is of no value and they remove it. Guess what, all the other functions which called this function is also broken now. Do you realize the importance of it now?
Well, if I had just a simple test as this:
assertEqual(actual, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10])All of the above problems would be solved because as soon as the maintainer removes the ‘equal to’ in the code, this test will fail and they’ll know that the function no more exhibits expected behaviour. This further clarifies that
Test serves as documentation
If we’re convinced that writing tests is important, it is more important to have the right tests and also keep the tests clean.
Not having the right tests is as good as not having tests at all!
But hey, that’s for another blog. One test at a time 😉
