In the realm of computer programming there are several ideas involving the testing and vetting of code to make sure it is ready to use. Many of these ideas are evolutions of previous methods or are new ways that people have developed to test code while it is being developed. One of these methodologies is called Unit Testing.
Unit Testing is part of a greater software development methodology called Test Driven Development. In Unit Testing, the code is broken down into to small sections or sub-sections called units. These units then have independent tests created that are designed to make sure that particular unit of code meets design, tests for bugs and works per the specifications. This method isolates different parts of the code and ensures that each piece works regardless of the other pieces.
There are several up-sides to Unit Testing: by isolating the unit pieces from the rest of the system you can make changes to the different pieces and test that the changed code is working correctly before you have to look at the repercussions on the rest of the system. This creates and facilitates change in the code and helps when making revisions to a large code-base. Getting your developers to begin thinking in a test-driven way can get them to create better code since they are continuously thinking about breaking it. Unit Testing also gets your developers to begin evaluating all of the requirements that the code must meet up-front instead of just jumping in to find out later the code needs to be changed to meet all of the specifications. As you can see, these are all good things that will ultimately help you end up with better-developed code.
Unfortunately, the number of developers that actually support Unit Testing in their development is small. Why? Well, Unit Testing sounds great on paper but in practice it can take a large amount of time and effort. Programmers have to create the Unit Tests as well as the code they are testing. Since Unit Tests are best written by the programmer that wrote the original routine, this can place a large work-load on a developer that may only have a short time-frame to complete their portion of the project. The key to Unit Testing really seems to be management support. Since Unit Testing is only as effective as the effort that is put into it, managers and project leads should realize that programmers need adequate time to write the code and the tests as well as fix any issues that arise in testing. Performing Unit Tests with a mediocre effort, inadequate time or only a partially through a project doesn’t do anyone any good.
Unit Testing and other methods of Test Driven Development can be worth the extra effort if care is taken to do them right from the beginning. Managers and administrators should use these tools as more than buzz-words for executives and show the benefits that the extra time can give. Unit Testing usually leads to the code needing less time with Quality Assurance/Testing departments, less time testing in beta environments and less support requests that need to be handled.
Ultimately, a good set of Unit Tests are like a shield for your code-base. You should maintain them, protect them and cherish them; they are the ones that will protect you and your code from previous errors, bugs and nasty situations. As your library of Unit Tests grow, you will begin to see how much your code writing has improved as well as the quality of your product from the process, and you will have a very valuable tool to help you with your continued development.