Everyone agrees that testing is a good thing. Not everyone agrees on how much testing is cost-effective and what exactly the kind of testing is right for a specific piece of software or product. But automated unit tests cam help you ensure your software is healthy.
Unit tests operate on the smallest possible section of code, on logical modules. In software design, a program of any decent size will be broken down into modules. These modules have inputs, outputs and behaviors. These inputs and outputs and behaviors are used by other parts of the program to perform work and can be monitored or tested by the test software.
Often, a software module is deeply bound up inside the containing framework and it is not obvious how to test a subset of the code in isolation. (Testing multiple modules together is referred to as “integration testing” and will be discussed in a later post). Fortunately, there are software constructs available to mimic or “mock up” objects which the module under test needs.
A case in point is a product we are revising called ILINX Release Script 9.0. The ILINX Release Script is a module which is run mainly inside the process space of Kofax’s Ascent Capture product. There are a number of complex environmental elements which supply runtime context for the various ILINX components.
Because we are developing in C#, and are using the NUnit testing tool, we are able to make use of the NUnit’s Mock objects to help in mocking up objects to test against.
By stubbing out the functionality of the execution context, we are able to exercise specific portions (or units) of code with very specific and controlled data and confirm the software’s behavior and output. If you are using .NET, I encourage you to look into NUnit (http://www.nunit.org/index.php) it’s ability to generate Mock objects.