Theory of usage

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. If one or more, of these object files 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 object files is called a unit. The TestApe instrumenter combines these units with the framework, the TestApe tests and with mocks for the functions in missing object files, in order to turn it all into a TestApe executable.

When running a TestApe executable the behavior of the unit is tested using the TestApe framework and the result of the tests are reported as shown below

 In stub execute
 
 PASSED verify command
   expected .......... [000] 6c 69 6e 6b 20 40 74 65 'link @te'
   actual ............ [000] 6c 69 6e 6b 20 40 74 65 'link @te'
 
 PASSED verify file existence testape_prelink_args
   expected .......... testape_prelink_args
   actual ............ testape_prelink_args
 
 PASSED verify file size testape_prelink_args
   expected .......... 52
   actual ............ 52
 
 PASSED verify testape_prelink_args
   expected .......... [000] 6d 79 6f 62 6a 2e 6f 62 'myobj.ob'
   actual ............ [000] 6d 79 6f 62 6a 2e 6f 62 'myobj.ob'
 
 PASSED verify ret_val
   expected .......... 0 (0)
   actual ............ 0
 
 PASSED test instrument_testape_lib

The entire process can be automated and run repeatedly. A TestApe executable is typically run, whenever one of the modules in the unit has changed. The test verifies that the new functionality behaves as expected ,or that the unchanged part of the unit is still working.

testape