“Unit Testing ?”
“Yes, dear Watson. Unit Testing.”
“Never heard of it.”
“That is not too surprising for me considering the amount of time you spend debugging and fixing the code once the QA people warm up.”
“Is it some kind of magic wand which makes all those bugs disappear?”
“No…not really. Considering your commendable interest in magic and stuff, I would put it this way – its more of a Guardian Angel who shines upon you while you code.”
“Really? Thats cool. Where and how can I obtain the services of one of these Guardian Angels?”
“You cannot buy one. You should create your own, through what I call a paradigm shift.”
“What is this thingy which you call a paradigm shift?”
“It is called Test Driven Development.”
“All these new terminologies are breaking havoc on my poor brain. First of all, please enlighten me on what a Unit Test is.”
“A Unit Test is a piece of code – usually written by the developer himself during the development process itself – for testing a small and specific functionality of his application code.”
“But why would anyone in his senses do that kind of a thing?”
“You could know that your code does what you intend it should do, everytime.”
“Could you give me more context on this ?”
“Sure, building on a solid foundation is the only way to build anything that will stand the test of time whether it be constructing a building with 100 floors or developing an application. That is not to say that what is built on top of the foundation is not important but if you are building on top of something you had better make sure what lies beneath is trustworthy. While developing an application we usually write some methods which will be used in other methods which in turn will be used in yet other methods and so on. If your first method has some bug then all your other methods are implicitly buggy as well, even though they might not introduce any bugs on their own. You are building on a weak foundation.”
“But wont I find those bugs when my application is tested after the coding is complete?”
“Yes, probably you would, but consider the situation in which your method works correctly for some parameters but not for others. The bug might get detected during the testing phase or after production roll-out depending on how lucky (or unlucky, if you so prefer) you are. And you surely know its least expensive, in terms of effort and money, to fix a bug at the earliest time possible.”
“That is great, now tell me please, what is this test driven development ?”
“Now that you know what unit testing is, you almost know what test driven development is. Test driven development goes like this – You write a test first. Run it. It should fail since you havent written any functionality yet. Now add the mininum code so that the test passes. Refactor. Repeat this cycle till your method has all the required functionality and all the tests pass.”
“Are you meaning to tell me that I should write my test even before writing any code for the functionality.”
“You couldnt be more close to the truth, dear Watson. Whenever you add a new functionality, the first step should be to write a Unit Test that anticipates and uses the new code. After you run this test which would fail, add new code and re-test to verify it. Apart from verifying that your new code works, Unit Tests force you to think in advance about the best way to write your code. By regularly following this idiom you can write solid, well-designed code.”
“Sounds like this Unit Testing idea is a good one.”
“Yes it is. But like everything good, it comes for a price.”
“How is that ?”
“You have to put in some effort to create the Unit Tests. The effort also includes thinking of how you want your code to work and how to test whether it does the same as well writing the actual testing code. As a one time investment you need to learn to the Test Driven Development paradigm, which is not very hard as you will soon see. Once you get the hang of it you would never want to go back to your style of programming.”
“But wont it take too much time to write the tests?”
“If you dont write unit tests, you would probably spend more time debugging and fixing your code. If you write unit tests, you would immediately know it if any change you make to your code broke something else. This could save you much time which you would be spending trying to find out what broke your code which was working all the me. Additionally, the unit tests acts as ‘executable documentation’ for your application code.”
“But shouldnt the QA people be doing the testing anyway?”
“Yes, they should be doing it. But unit tests would be testing the code at the lowest level and actually complements the functional testing. If you have written good unit tests, there will be much less to fix in the functional testing phase.”
“I guess I am convinced of having my own Guardian Angel. How do I start ?”
“You can start by making use of an infrastructure which will help you create and run Unit Tests for your code. Such frameworks are readily available today.”
“I’ll bet these frameworks are pretty expensive. My boss would never approve.”
“If you start betting like this, I am sure you are going to lose a lot of bets. You can get Unit Testing frameworks for free.”
“Free…?!!!”
“… as in freedom as well as free beer. I would recommend you look at NUnit. You can download a copy of the NUnit unit testing framework from NUnit.org”
Leave a comment