Discovering the Benefits of Unit Testing and TDD

In the past few years I kept hearing the term unit testing pop up here and there.  I seemed to always brush it aside, I figured I would eventually find time to learn about it what it is and why I kept hearing so much buzz about it.  Well I finally found the time when I was developing my picture in picture tool.  And I must say, I am now convinced of how awesome it is.

I won't go super in depth, there are plenty of blogs, documentation and the like that go over the details of unit testing (python docs link).  I will say that when utilizing unit testing, I feel much more confident in the stability of my code and my ability to track down future bugs.

Unit testing in general can be described as implementing small testing methods that validate small bits of actual code.  It may seem silly to write "test code" for your code.  Typically what I refer to as "linear coding", you end up testing your code yourself while you write it.  So why spend all that extra time on code that isn't used within the tool?  Sanity, is my answer.  I've built small tools and large tools, there are always easy bugs and hard bugs to find within the code.  Sometimes finding a bug is simple, but it's always at least a matter of minutes to fix something, and it would be nice if I could apply the fix, have all my tests pass with said fix and be confident that the code is now fixed as well as stable.  After spending the time reading up on unit testing, I found that I regretted not researching it sooner.

Along my path of learning about unit testing, I have also created an initiative at work to try and train the rest of the TAs to understand and implement unit testing within their normal tool development process. While researching unit testing, it eventually lead me to learning about Test Driven Development (TDD).

The concept of TDD, being that you start with writing your unit tests that are setup to actually fail, that failure then prompts you to create the code to make the test succeed, and as you add new code you refactor the existing code.  I actually really enjoy this methodology, as it is a very helpful guide to creating very stable code.  I have noted a few helpful things I have been practicing this on my own..

• Write a lot of useful and relevant unit tests, I found that breaking my code down into testable chunks helped me to consider all the areas that could have led to possible future bugs.  This actually helped me in understanding why some pieces of code could be more bug prone.  The more tests, the more detailed report of the stability of your code.  Along with this, I would be sure those test functions are very narrow and focused on a specific testable variable.

• Find a new bug? Write a new test if you can, and add it to your test suite.  This will help continue the population of updated unit tests and will help keep your code stable as bugs are fixed.

• Readability and good commenting count, especially in your test suite methods!  The point of these unit test suites is to improve the quality of your code and to assist in future bug fixes.  It's always good to consider the future bug fixer may not be you.  So commenting and properly naming the unit test function is essential.  The entire purpose of running the test suite is to quickly find bugs, if it's difficult to read or understand what the test suite is doing it may slow down the process of fixing said bug(s).  I tend to like the function naming that most people suggest: test_import_module_validation() instead of something like test_import().  In this instance, try to avoid short handing the name of a function.

• Take advantage of the error message argument within the assert functions.  The purpose of these unit tests is to provide success/failure checks along with information, the error message is a great opportunity to provide more information to the test runner on how the test failed. It's great to use unit tests within TDD to make guide you in creating solid code, but always remember that the person doing the tests in the future may not be the original author, so the more information the better.

• Not necessarily related to learning/writing unit tests, but if you are learning with the goal of implementing this among a team it's a good idea to document everything.  What it is, how to use it, best practices, pros, cons - the works.  Provide a path for the team to learn the information (direction), encourage them to refer back to the information (documentation) when needed, and also give them a time to learn it (training).