In one of my previous posts I talked about maintainable code and one of the key points I mentioned was unit testing and writing unit test. I would like to describe what are the most important reasons how writing of unit test will make your life easier, your programming faster and help you produce more robust results.
Speed of development
How many times were you updating some feature in the business logic and with each code change you had to rebuild the app, refresh the website, navigate over 2 previous pages of the wizard to check the functionality that you just changed to only realize that something is not working and you see the yellow ASP.NET error page because of NullReferrecneException or similar error? I have done it many times and still do it sometimes when I am too lazy to write a unit test;)
There are situations when you need to test and debug the new functionality within the UI flow, however there are many situations in which writing a good set of unit tests lets you to develop and troubleshoot the functionality by running from unit tests independent on the website and then after all works verify the final result in the UI.
For example let’s say you are adding some custom validation logic, set of business validators emitting errors with a processing framework around it and you need to finish this framework first and then you want to integrate the validation into your pages. Now you could be hacking the invalid inputs in the page to trigger the validation and check how it is working or you can debug with unit tests much faster and then when all is working you just connect the validation result and make sure all works on the page as well.
Validation of changes
You probably know the bad feeling when you need to change some complex code that someone else wrote. Let’s say you have to add processing of new item type to the business logic, that will slightly change the workflow. Or maybe even you wrote the logic a year ago and you only remember there were some complex conditions, but you do not remember all the details. You will have to analyze the code anyway, but let’s say there is a set of unit test ready which proves that the processing works in the expected way and produces the expected result for the existing item types and the code already in place.
You can add the changes that you need and with the unit tests at your hands you can verify easily that the existing functionality was not broken by your changes. This gives you much more confidence that the updated code will be robust. And seeing the unit test should encourage you to write a couple of more to cover your new code as well;)
Unit test are also very useful in bugfixing. The ideal bugfixing scenario (at least for some more complex business logic) should be to write a unit test that shows the error (or more for multiple error conditions) first. Then you can fix the code and easily verify that the unit test show “green” result and the bug was fixed.
It might be also a good idea to cover the originally working flow with unit tests to make sure the fixes did not actually break something that was working originally.
I am very happy if you have gone this far through the boring, yet important topic of unit testing;) These are the main advantages I see in using the unit tests. In my next post I will cover what I think that are the best practices to write good and easy-to-use unit tests, based on my experience.