Unit testing with TestApe

In classic software development, a modest complicated software program is typically decomposed into several cooperating modules. The compiler interprets the source code for each module and creates an object file holding the compiled code. The linker assembles all the object files and creates the complete executable.


The sample program prg, consists of 9 modules prg_a - prg_i

If one or more, of these modules were not present, the linker could not assemble the software program and it would not be able to execute. In TestApe terminology, an incomplete assembly of modules is called a unit. See also Using the TestApe instrumenter


One possible unit composed of some of the modules from prg

The individual modules in the unit, can be source files, object files or library files. The amount of modules in the unit determines what functionallity that is tested. As each module might be delivered at different times by diffrent groups of people, it is possible for each group to define units that makes their code testable without relying on the deliverables from other groups. Check out other good reasons to do unit testing

The TestApe instrumenter combines the selected modules with the framework and the TestApe tests in order to turn it all into a TestApe executable. modules.


The instrumener fill in functionality for the missing files prg_c, prg_d, prg_f and prg_h.

The TestApe tests are engineered by the software developer to test this particular combination of modules. For example test_code.c shown below, will test the unit composed of the source files prg_a.c prg_b.c prg_e.c prg_g.c prg_i.c 

  void test_prg_a_init_failed(void)
    {
    // prg_a_init must first call prg_c_init.
    // If the call is detected, then the framework
    // will return INIT_OK from prg_c_init
    SIMULATE(prg_c_init, INIT_OK);

    // prg_a_init must then call prg_f_init.
    // If the call is detected, then the framework
    //  will return INIT_FAIL from prg_f_init
    SIMULATE(prg_f_init, INIT_FAIL);

    // Nu further function calls are expected
    //  after this. If more are called, we found an
    //  error

    // Now, stimulate prg_a, by calling prg_a_init
    // and verify that a failing prg_f_init causes
    // prg_a_init to return FALSE
    VALIDATE(prg_a_init(), FALSE);
    }

To produce the test executable using automatic instrumentation of stubs, invoke the following command line:

testape gcc test_code.c prg_a.c prg_b.c prg_e.c prg_g.c prg_i.c testape.a -o test

There are many other ways to write tests. The framework can be adapted/extended to suit the needs of your application. More information of the possibillitites can be found here in Using the testape library.

If you want to try it out yourself, you can find the download section here

Menu

TestApe

Documentation

Downloads

News

The latest headlines from Testape.com

TestApe CygWIN support released, Jun 19th 2008

A minor update has been released in order to support GCC when running in a CygWIN environment.

more

TestApe first beta released, Aug 23th 2007

This years major update has been released. It includes a reference manual and macros to support test parameters and improved usage of the automatic stub instrumentation.

more

Site improvements, Aug 23th 2007

The site has been updated. The webtty package has been tugged safely away in the corner and the TestApe ...

more