An introduction to Unit Testing

Introduction

We have already seen in previous articles that the software life cycle is made of briefly five steps.

• design and analysis
• coding
• testing
• deployment; and
• maintenance.

As software gets larger and more complex, it is very important to devise different methods that will help both coders and testers make sure that the program is performing normally; producing expected results with the smallest number of errors.

When a program consists of millions of lines, it is incredibly difficult to control each module - sometimes called functions or procedures - this difficulty increases the possibility of errors. Although these modules are defined by design, coders may need to add or remove some modules depending on their specific purposes. No matter the number of modules, it is important to define the mechanisms to check that each of them is working perfectly.

These mechanisms are known as unit testing. Because of the diversity of the modules, each test suite should ideally be unique. That is there should not be a single test case for all methods of the program. Mock or fake objects and test harnesses may be used to test each module.

It is also important to note that unit tests make use of both black boxes and white boxes. In the article defining code coverage, I mentioned that code coverage was another type of white box testing. Now we delve a little deeper into that kind of box. Why is it white? The answer is shown next.

White box testing

The white box illustrated in the middle of the picture provides all tests assessing results from the inputs. These inputs need not be correct as error handlers will monitor them.

White box testing presents several benefits:

• The tester is aware of all error handling mechanisms of the box.
• The tester can write tests to check the correctness of all pathways.
• Unit testing, being more complete, is a kind of documentation guideline that the coder or tester can use when actually writing the code in the box (computing modules)
• All resource dependencies are known beforehand

In the "write the test first" scenario, the ability to write complete tests is vital information to the coder or tester who ultimately implements the code, therefore a good white box unit test must ensure that, at least conceptually, all the different pathways are exercised.

Another benefit of white box testing is the ability for the unit test to inspect the internal state of the box after the test has been run. This can be useful to ensure that internal information is in the correct state, regardless of whether the output was correct and even though classes are often implemented with many private methods and accessors.

With all these benefits, we can easily understand why code coverage is just another type of white box testing.

Limits of unit testing

Like all forms of software testing, unit tests can only show the presence of bugs; they cannot show the absence of bugs. Unit testing cannot be used as a tool to detect bugs in a program.

To obtain the maximum benefits from unit testing, rigorous discipline is needed throughout the software development process. It is essential to keep careful records, not only of the tests that have been performed but also of all changes that have been made to the source code of this or any other unit in the software.

There are also other setbacks that are beyond the scope of this article.

Applications

In order to put an end to these articles, I will briefly give some applications of unit testing.

Unit testing is extensively used in extreme programming and code coverage tools.

INSERT UNIT TESTING APPLICATIONS