How to use new unit testing tools & techniques to improve software quality
Beyond unit test
For some, the terms "unit test" and "module test" are synonymous. For others, the term "unit" implies the testing of a single procedure, whereas "module" suggests a collection of related procedures, perhaps designed to perform some particular purpose within the application.
Using the latter definitions, manually developed module tests are likely to be easier to construct than unit tests, especially if the module represents a functional aspect of the application itself. In this case, most of the calls to procedures are related and the code accesses related data structures which makes the preparation of the harness code more straightforward.
Test tools render the distinction between unit and module tests redundant. It is perfectly possible to test a single procedure in isolation and equally possible to use the exact same processes to test multiple procedures, a file or multiple files of procedures, a class (where appropriate), or a functional subset of an entire system. As a result, the distinction between unit and module test is one which has become increasingly irrelevant to the extent that the term "unit test" has come to include both concepts.
Such flexibility facilitates progressive integration testing. Procedures are first unit tested and then collated as part of the subsystems, which in turn are brought together to perform system tests.
It also provides options when a pragmatic approach is required for less critical applications. A single set of test cases can exercise a specified procedure, all procedures called as a result of exercising the single procedure as illustrated in Figure 2 below, or anything in between.
The use of test cases which prove the functionality of the whole call chain are easily constructed. Again, it is easy to "mix and match" the processes depending on the criticality of the code under review.
 |
| Figure 2: A single test case (inset) can exercise some or all of the call chain associated with it. In this example, "AdjustLighting", note the red colouring highlights exercised code. |
This all embracing unit test approach can be extended to multithreaded applications. In a single-threaded application, the execution path is well-defined and sequential, such that no part of the code may be executed concurrently with any other part.
In applications with multiple threads, there may be two or more paths executed concurrently, with interaction between the threads a commonplace feature of the system. Unit test in this environment can ensure that particular procedures behave in an appropriate manner both internally and in terms of their interaction with other threads.
Sometimes, testing a procedure in isolation is impractical. For instance, if a particular procedure relies on the existence of some ordered data before it can perform its task, then similar data must be in place for any unit test of that procedure to be meaningful.
Just as unit test tools can encompass many different procedures as part of a single test, they can also use a sequence of tests with each one having an effect on the environment for those executed subsequently.
For example, unit testing a procedure which accesses a data structure may be achieved by first implementing a test case to call an initializations procedure within the application, and then a second test case to exercise the procedure of interest.
Unit test does not imply testing in only the development environment. Integration between test tools and development environments means that unit testing of software can take place seamlessly using the compiler and target hardware.
Loading comments... Write a comment