26 Sep 2006 Read how component tests can be developed without driving the generation from the Test Realtime GUI.
System requirements
Overview
This is an IBM® Rational® Test RealTime component testing example which shows how Component Tests can be developed without driving the generation from the Test Realtime GUI. This example is based on a real customer engagement with IBM Rational. Some customers have found it to be more convienent and easier for the developers when the Component Tests can be generated as part of their build scripts. This is especially true when a customer has a complex build environment.
A customer also found it simpler to use when the Component Test driver (in other words, the .c file that is produced from the .ptu file) is compiled and linked with the rest of the application. This is not the normal procedure when building via the GUI. In the GUI case, a developer has to decide which files they want to include in the build. This process can become a little tedious. However, by linking the Component Test driver .c file with the rest of the application, all the necessary symbols are included. This of course will cause some duplicate symbol issues: the Component Test driver will have its own main() routine, as well as any routines that have been stubbed. These may be just a warning, and in other cases it may be necessary to remove object file(s) from the link.
By modifying the makefile to add rules to generate and compile the Component Test, it ensures consistency in that all the files are compiled with the appropriate options. If a user has to update option information within the Test RealTime GUI, problems can occur because of incorrect flags or include path search lists. This approach saves users the trouble of updating the same build information in multiple locations.
There are still three distinct stages to using this approach. First the Component Test script file (.ptu) must be produced. The user then modifies this template with any editor and adds in the appropriate test cases. Once completed, the user will compile the test script (in other words, generate the .c and compile it with their compiler of choice) and then link this with the application.
This example was built in order to assist with modifing a customer's makefiles. It shows the basic commands that need to be included in a customer's build rules to build and also the post-execution commands required to produce the report information.
Instructions
After unzipping to a directory, edit the file runCompTest.bat to modify the path information for the environment variables at the top and for the path to the Microsoft linker exe farther down. After modifying the .bat file above,
cd CommandLnCompTest
rem the syntax is ..\runCompTest.bat <source file> where <source file> refers to the name without the .c extension
..\runCompTest.bat mytest
This directory also includes a Perl script called stripPTU.pl which can be used to produce a ptu file which can be included in another ptu file for regression testing. Ordinarily, the PTU file generated by the Component Test wizard will have some keywords which prevent it from being included in a hierarchical ptu file approach. This script removes the offending keywords and the ptu file then can be referenced in another ptu file with a line like INCLUDE PTU "foo.ptu".
Download | Description | Name | Size | Download method |
|---|
| Example files | cmd_line_tst.zip | 7 KB | HTTP |
|---|
Resources
| 
