Unit testing might sound a little technical but don’t let that scare you. I would try and explain in simple terms what it is and why it should be done.
Let me first put some context in place. If you put carrot in a juicer at one end and you get nice carrot juice at the other and you are not aware of the internal working of the juicer, then that juicer for you is a black box. You couldn’t care less whether there is complex machinery inside or just a small gopher that squeezes the juice out of the carrot and pours it out. That’s what a black box is. You provide input and you get output while being oblivious to internal processing.
Black box testing gets its name from the above concept of a black box. You provide input on a form in a software application (consider fields like name, occupation, organisation etc.), you get output (for example, a neatly formatted visiting card layout), and then you test that output against the expected result. This testing is not concerned about the internal working of the application that did the job.
The opposite of black box testing is called white box testing (also called glass box testing or clear box testing). Here the focus is on the internal working of the object in consideration (piece of machinery, piece of code, etc.). White box testing in software looks at how the code runs on the inside. Unit testing is a type of white box testing. There are classes (abstractions of real world objects, for example, a phone), their methods (functions that a real world object does, for example, make a call), and their properties (attributes of the real world object, for example, phone number). Unit testing checks each of these classes and their methods (and some more).
Consider a login page page of an application that allows the user to login by specifying his email and password. A simple way would be to check for the presence of entered email in the database and then match the password with that in the database. In case of absence of the email in the database or mismatch of the password, an appropriate message would be shown to the user. Implementing this kind of logic would require some kind of if-then-else code (called conditional logic). Greater the number of conditions in the business case, greater would be the number of if-else blocks within the code and, ergo, the number of permutations that can result.
A good developer would test each of these conditions to ensure that no scenario causes the code to break. However, doing this testing via black box approach would not be possible. This is where white box testing comes to the rescue. Unit tests (a unit can be considered a small piece of code that can be tested independently) are written within the code that test each scenario. Every time the developer makes a change to the code, he runs all the test cases to ensure they are passing (meaning no change is causing the code to break). This greatly increases the quality of the code, raises the confidence level of the developer for his code, and, most importantly, makes the code maintainable. Every time you make a change, just run the test suite (all the test cases combined) and, voila, you would know whether all’s well with the application or it is behaving erratically somewhere.
The above scenario is just one example of how unit testing can help the code. Unit testing goes a long way from testing simple if-then-else blocks. A good test suite (and the corresponding pass/fail ratio) can be a good metric of the code quality and maintainability. However, writing unit tests takes time comparable to writing the original code itself. So writing unit tests can be a little expensive if cost is the primary focus of your application. But if you are looking to have a robust application that can be built iteratively while keeping the quality intact (or raising it), unit testing would be your best friend.
When software projects are handed over from one vendor to another vendor for maintenance, one of the primary metric that gets looked at is the quality of unit tests – pass/fail ratio and the code coverage (how well do the existing unit test cover each scenario). Anyone who has read a programming book can write an application that can satisfy business requirements. But what separates the men from the boys is the level of unit testing done and code quality. So if you are looking to build an application that you would like to continue to improve upon and tune as per the markets, make sure you ask your developers, “hey, do you guys do unit testing?”.