Module Tests

Module tests are typically dynamic white-box tests. This requires the execution of the software or parts of the software. The software can be executed in the target system, an emulator, simulator or any other suitable test environment. Within the range of dynamic tests the state of the art distinguishes between structural and functional tests. The structural dynamic tests are also called "module tests" or "unit tests". A module test is performed with the knowledge of the module internals in mind. I.e. especially the branches and paths in functions and modules.


The focus of the tests is:

Set up of regression tests. This means the test environment once set up for a function can be re-used to check its performance e.g. after maintenance. Coverage of the relevant state of the art test methods like equivalence class building, boundary value analysis and condition coverage. Easy generation of test cases for all possible combination of inputs to a function, e.g. to check a function for overflows, underflows or divisions by zero.

To perform the module tests you need a test bench. There are quite a number of professional systems available which either do testing in a PC environment or in the target hardware. Generally you can say that everything needing a target hardware is a headache. The target hardware might not be your exact target system, but an evaluation board. However if this is the case there is not much benefit, because the integration into the target system will be never complete and valid. The better approach would be to keep hardware related parts of the program in a dedicated HW abstraction layer. This part has to be then tested in a special environment (e.g. the emulator). All the rest of the software is standard C and could be also tested on a PC based environment. We are doing our tests in a Perl script environment. It is easy to use and the best thing about it is that it is easily available to everybody and it does not cost a cent.

How does our Perl based test environment look like?

The test environment is all contained in a Perl script. It uses the Perl "Inline" package, which has the feature to use C - functions from the Perl script. To achieve this the script has two parts. At the top there is the Perl part which is appended by a C part. The general procedure is to execute the main Perl script part. Perl then will automatically setup sub-directories, compile the C part and build a DLL. The Perl script will then use the functions in the DLL as required. This means that global variables within the DLL can not be accessed by Perl, besides the fact that the data model in C and Perl is quite different. To access global variables it is necessary to write so called "get" functions to read them and use them in Perl. This is for the purpose to evaluate results. To set input values for the test of a C function so called "set" functions have to be established.

The operation flow is then as follows:

Open a log file where all subsequent results will be written. Write the header of the test log to the log file. Call the init routine of the C-part of the test setup. Set the input(s) to the C-function using the appropriate "set-function(s)". Execute the function (test object). Read the outputs of the C-function using the appropriate "get-function(s)". Write the result (outputs) including the original variable name used in the C-function to the log file. Repeat steps 4 to 7 with new input data as often as this is required. Write the trailer to the log file which states the function name which was tested.

If the same test step is used multiple times with varying data it is recommendable to use nested "for" loops to get a combination of all possible input data.

Example of a use case to test a proprietary division function

For a microcontroller application a proprietary division function had to be written. You could not simply use c = a / b; because this would eventually lead to exceeded runtime, since the normal division made use of a lengthy library function provided by the maker of the compiler. A smart solution for a very fast division function was found, but how to make sure that it gives the same results as the standard division on any other computer?

The following test approach helped to develop the function (it had some rounding problems in the beginning), and finally gave the prove that the new function has the same performance as the standard division: