Using mkodt

RADE	C++ Unit Test Manager	Using mkodt Creating and running test objects
Technical Article

Abstract

This article shows how to create and run test objects, and how to use the commands and their options.

Using SetOdtParam

Selecting the Operating System to Replay a Test Object
Modifying the Maximum Replay Time of a Test Object

Using WhichDir
Using ODTInit
Using mkodt Options

Using Basic Options
Using Concatenation Options (-p and -r)
Informations/best practices about the modules/libraries loading
Using -NOMaxTime Options
Using a Debugger (debug on Windows)
Changing the Output Directory
Using Others Options: -q, -X, -html, -xml, -l, -L

Using SetOdtParam

SetOdtParam enables you to select the operating systems with which you want the test object to be replayed, and to set the maximum replay time

[Top]

Selecting the Operating System to Replay a Test Object

By default, a test object is replayed with any operating systems available on your site. If you don't want to replay a test object with a given operating system, use:

SetOdtParam Replay_xxx=NO

where xxx can have the following values: AIX, SunOS, HP-UX, Unix, Windows_NT, aix_a, solaris_a, hpux_b, and intel_a.

Examples:

To prevent a test object to be replayed with intel_a:

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

SetOdtParam Replay_intel_a=NO
LOAD
exit $?

To replay a test object only on AIX:

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

SetOdtParam Replay_Windows_NT=NO
SetOdtParam Replay_solaris_a=NO
SetOdtParam Replay_hpux_b=NO
LOAD
exit $?

[Top]

Modifying the Maximum Replay Time of a Test Object

The default replay time of a test object is five minutes. To modify this replay time, add to the test object script:

SetodtParam max_time=xx

where xx is the maximum replay time you want to set. It can't exceed 60 minutes.

Example:

The following example shows a test object with a maximum replay time of ten minutes that will be replayed with Windows only.

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

SetOdtParam max_time=10 SetOdtParam Replay_Unix=NO LOAD exit $?

[Top]

Using WhichDir

This command can be used in shell script to find a directory or a file in the workspace concatenation using the ADL_ODT_CONCATENATION variable.

Example: This test object that doesn't replay with Windows is going to find in the workspace concatenation the file Visualization/Data.d/cubes.cgr and to copy this file in the directory set by the ADL_ODT_TMP variable with the name sample.cgr.

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

SetOdtParam Replay_Windows_NT=NO cp $(WhichDir Visualization${ADL_ODT_SLASH}Data.d${ADL_ODT_SLASH}cubes.cgr ${ADL_ODT_TMP}${ADL_ODT_SLASH}sample.cgr chmod ugo-w ${ADL_ODT_TMP}${ADL_ODT_SLASH}sample.cgr LOAD ${ADL_ODT_TMP}${ADL_ODT_SLASH}sample.cgr exit $?

[Top]

Using ODTInit

The ODTInit command is used to factorize steps od ODTs; Indeed, sometimes, ODTs could generate and use the same resources... But each ODT will create his own resources during a replay.

To use this command, the developer must create a shell script named ODTInit_logicname.sh in the ADL_ODT_IN directory. This shell will generate resources that will be used on this ODT.

Example:

In a test framework, some ODTs use the same Part; This Part is created in the ODT in an "initialization step"; For instance, we are going to take 2 ODTs:

ODT1.sh:

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

SetOdtParam max_time=30
OsName=$MkmkOS_NAME
RC=0
###########################################
PROGMF=DRWtstCreatePad
PROG=CNEXT
###########################################
echo Execution de $PROG sur $OsName, at `date` ;
echo
###########################################
$PROGMF $ADL_ODT_TMP > $ADL_ODT_OUT/$PROG
MODEL=$ADL_ODT_TMP${ADL_ODT_SLASH}${PROGMF}.CATPart
echo "=> Model = $MODEL"
ls $MODEL ;
RC=$?
if [ $RC != 0 ]
then
echo "*********"
echo "********* $PROG sur $OsName, EXECUTION KO: $MODEL NON TROUVE" $RC
echo "*********"
RC=32;
exit $RC
fi
CNEXT $MODEL
exit $?

ODT2.sh:

SetOdtParam max_time=30
SetOdtParam max_time=30
OsName=$MkmkOS_NAME
RC=0;
###########################################
PROGMF=DRWtstCreatePad
PROG=CNEXT
###########################################
echo Execution de $PROG sur $OsName, at `date` ;
echo
###########################################
$PROGMF $ADL_ODT_TMP > $ADL_ODT_OUT/$PROG
MODEL=$ADL_ODT_TMP${ADL_ODT_SLASH}${PROGMF}.CATPart
echo "=> Model = $MODEL"
ls $MODEL ;
RC=$?
if [ $RC != 0 ]
then
echo "*********"
echo "********* $PROG sur $OsName, EXECUTION KO: $MODEL NON TROUVE" $RC
echo "*********"
RC=32;
exit $RC
fi
CNEXT $MODEL
exit $?

In these two ODTs $PROGMF runs to create a part named ${PROGMF}.CATPart;; So, this part is created by these 2 ODTs but it's the same part. In a replay, the part is going to be created twice. The purpose of ODTInit is to create this part once in a replay!

For that, it's necessary to create a shell in ADL_ODT_IN named ODTInit_DRWCreatePad.sh; this shell will create the part:

ODTInit_DRWCreatePadGenUI.sh:

SetOdtParamInit max_time=15

DRWtstCreatePadGenUI $ADL_ODT_TMP > $ADL_ODT_OUT${ADL_ODT_SLASH}CNEXT return $?

The SetOdtParamInit max_time can be used since CXR15. Using this, it's possible to add tim to the ODT that launch the ODTInit command.

ODTs are going to be modified:

ODT1.sh:

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

logicname=DRWtstCreatePadGenUI
#INITIALISATION :
#################
ODTInit $logicname            
SetOdtParam max_time=30
OsName=$MkmkOS_NAME
PROG=CNEXT
RC=0;
MODEL=$ADL_ODT_TMP${ADL_ODT_SLASH}${PROGMF}.CATPart
echo "=> Model = $MODEL"
ls $MODEL ;
RC=$?
if [ $RC != 0 ]
then
echo "*********"
echo "********* $PROG sur $OsName, EXECUTION KO: $MODEL NON TROUVE" $RC
echo "*********"
RC=32;
exit $RC
fi
CNEXT $MODEL
exit $?

ODT2.sh:

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

logicname=DRWtstCreatePadGenUI
#INITIALISATION :
#################
ODTInit $logicname
#SetOdtParam Replay_Windows_NT=NO
SetOdtParam max_time=30
OsName=$MkmkOS_NAME
RC=0;
PROG=CNEXT
MODEL=$ADL_ODT_OUT${ADL_ODT_SLASH}${logicname}${ADL_ODT_SLASH}${logicname}.CATPart
echo "=> Model = $MODEL"
NEW=$ADL_ODT_OUT${ADL_ODT_SLASH}${PROG}.CATDrawing
ls $MODEL ;
RC=$?
if [ $RC != 0 ]
then
echo "*********"
echo "********* $PROG sur $OsName, EXECUTION KO: $MODEL NON TROUVE" $RC
echo "*********"
RC=32;
exit $RC
fi
CNEXT $MODEL
exit $?

The ODTInit command will run the ODTInit_DRWRecCreatePadGenUI.sh file if the part had not been already created by another ODT. This command create a directory under ADL_ODT_OUT, named DRWRecCreatePadGenUI to save results of the Init step (a file Result.ODTInit, a file DRWRecCreatePadGenUI.traces and in our example, DRWRecCreatePadGenUI.CATPart).

If you run these 2 ODTs with mkodt:

mkodt -s DRWRecCreateAuxViewPtEdge_PartUpdate DRWRecCreateAuxViewPtEdge_Part

The .traces files generated by mkodt contain:

DRWRecCreateAuxViewPtEdge_PartUpdate.traces:

## ++ RESULT : Init OK.

Init TRACES :

the ODTInit output

DRWRecCreateAuxViewPtEdge_Part.traces:

## ++ RESULT : Init already OK.

Init executed by : DRWRecCreateAuxViewPtEdge_PartUpdate

Init TRACES :

the ODTInit output

If the Init step is KO, the return code of the ODT is 50:

If the Init step is KO, each ODT using the same init will have a return code 50.
If you want to update your output generated by the Init sequence in a Replay sequence, you have to delete the logicname directory.
NOTE : To be able to get an UUID associated with an ODTInit command (for example, for data creation in an oracle database using ODTInit command), a Unique ID is set since CXR14 level: ADL_INIT_UUID. Using this, you'll be able to point datas (created in a database for example) between ODTs that use the same ODTInit command.

[Top]

Using mkodt Options

Using Basic Options

These standard options are used to replay ODTs in a local workspace or in an official workspace:

Command Line	ODTs Replayed
mkodt -W MONWS -F MONFW -a ( option -W available on UNIX only)	Replay all ODTs of $HOME/MONWS/MONFW
mkodt -d /u/lego/CXR4/BSF -a -S -o /u/users/toto/output	Replay all Switch ODTs of CXR4 and generate Output in /u/users/toto/output directory
mkodt -s DRW*Rec	Replay all ODTs DRW*Rec of the current workspace.

[Top]

Using Concatenation Options (-p and -r)

Command Line	ODTs Replayed
mkodt -d \\renoir\CXR4\BSF -a -S -o E:\users\toto\output -p e:\steplib\CXR4\LocalWS	$ADL_ODT_CONCATENATION= e:\steplib\CXR4\LocalWS Runtime Concatenation = e:\steplib\CXR4\LocalWS
mkodt -d \\renoir\CXR4\BSF -a -S -o E:\users\toto\output -r e:\steplib\CXR4\LocalWS	$ADL_ODT_CONCATENATION=\\renoir\CXR4\BSF Runtime Concatenation = e:\steplib\CXR4\LocalWS
mkodt -d \\renoir\CXR4\BSF -a -S -o E:\users\toto\output -r e:\steplib\CXR4\LocalWS -p \\renoir\CXR4rel\BSF	$ADL_ODT_CONCATENATION=\\renoir\CXR4rel\BSF Runtime Concatenation = e:\steplib\CXR4\LocalWS

[Top]

Informations/best practices about the modules/libraries loading

The ODT is going to launch an laod module. How is this module found and how are the libraries loaded?

On windows :

The system is looking for the executable module in the PATH environment variable. When the module is found, the system launch it. If this module loads libraries, the system is going to look for these libraries using the following order :

- FIRST : Look for the library in the load module directory.

- SECOND : Look for in the system PATH.

So, to be able to load a modified library from a developper workspace in an ODT, this workspace must contain the executable module.

Example :

MONODT launch the load module MONMOD. This module is linked with MYLIB.dll

The workspace developper WSDEV has the following concatenation : WSDEV;WSPROJ;WSBSF

The developper modify MYLIB.dll and rebuild it in the workspace WSDEV.

During the ODT execution :

Workspace where MONMOD is found Workspaces where MYLIB can be loaded Workspace where MYLIB is effectively loaded

WSDEV WSDEV;WSPROJ;WSBSF WSDEV

WSPROJ WSPROJ;WSBSF WSPROJ

WSBSF WSBSF WSBSF

WSDEV WSPROJ;WSBSF WSPROJ

WSPROJ WSDEV;WSPROJ;WSBSF WSPROJ

WSBSF WSDEV;WSPROJ;WSBSF WSBSF

So, to be sure that the loaded library is the developper workspace library, copy the load module in the developper workspace!

On Unix :

The system is looking for the executable module in the PATH environment variable. When the module is found, the system launch it. If this module loads libraries, the system is going to look for these libraries using the LIBPATH environment variable (LIBPATH on AIX, LD_LIBRARY_PATH on SunOS and Linux). During the ODT execution, the environment variables PATH and LIBPATH contain the same concatenaition, so the developper ha nothing to do (no copy!) to be sure to load the correct library!

Using -NOMaxTime Option

This option suspend the supervision of max_time ODT:

Example:

For the following example:

export ODT_REQUESTED_PRODUCT="_AL2.slt+;_ME2.slt+"

SetOdtParam max_time=1 LOAD exit $?

mkodt without -NOMaxTime option:

Elapsed time > max_time; the ODT is killed.

mkodt with -NOMaxTime option:

Elapsed time > max_time defined in the shell (SetOdtParam max_time=1) because -NOMaxTime had been used!!!

[Top]

Using a Debugger

To debug a load module, you must use the -b and -B options:

Command Line	ODTs Replayed
mkodt -d E:\users\toto\MONWS -F FileMenu.tst -s CCPCutRec -o E:\users\toto\output -b CNEXT (intel_a)	The ODT CCPCutRec will be replayed and the load module CNEXT will be debugged with MsDev
mkodt -d /u/users/toto -s CCPCutRec -o E:\users\toto\output -b CNEXT -B dbx (aix_a	The ODT CCPCutRec will be replayed and the load module CNEXT will be debugged with dbx

Default debugger on the mkodt command is:

Windows: devenv (MicroSoft Visual Studio 7.0)
AIX: xldb
SUN: Workshop
HP-UX: wdb

To change this debugger, use the -B DebuggerName option; Others available debuggers are:

AIX: dbx
SUN: dbx

Debugging on Windows:
To use MicroSoft Visual Studio 7.0 (devenv.exe) as debugger, you must know which version of Visual Studio you use (7.0 or 71) and launch:
- For VC7.0 :
            mkodt -s MyODT -B devenv

            or :

            mkodt -s MyODT -B devenv -b Module
- For VC7.1 :
    mkodt -s MyODT -B devenv71

    or :

    mkodt -s MyODT -B devenv71 -b Module

devenv will be launched with your module to debug. By default, when you'll execute your module, you will have a window to save your solution. The solution file will contain your debug environment (opened sources in VC7, breakpoints,...). This file could be used for another debug with mkodt to keep your environment.

You have 3 possibilities :
- You do not want to save the solution and you do not want to have this window each time you launch mkodt in debug mode, you have to modify the following setting in VC7 :
  Click cancel in the Save FIle As window and your module will run.
  
  To modify setting to not have the Save File As Windows:
In VC7 window, select Tools->Options.

In the Options window, select Environment->Projects And Solutions;

In the Build and Run section, select Don't save changes to open documents :

Saving this setting, you will not have the Save As window launching your module in debug mode.

When you close the VC7 window, the following window will appear :

Select No to not save the solution file.
- You want to save the solution in the default code\bin directory suggested by VC7 if this directory is not read-only to use it later launching a new mkodt.
  In the Save As window, click on Save button( do not modify the solution name). Your solution file will be saved in the code\bin directory where the module was found.
  
  Then you can open source, add breakpoints and debug your module.
  
  if you want to load this saved solution launching mkodt, you just have to launch :
  
      mkodt -s MyODT -B devenv
  
      or :
  
      mkodt -s MyODT -B devenv -b MyModule
  
  If the solution file MyModule.sln is found in the same directory that MyModule.exe, mkodt will load it by default in VC7 to get your saved debug environment.
- You want to save the solution in another directory (not in the code\bin default suggestion) to be able to load it with mkodt later.

In the SaveAs window, select the directory (for instance, C:\Temp\MyModule.sln) where you want to save the solution file. Clikc on the save button. (You can also modify the solution name)

Then you can open source, add breakpoints and debug your module.

if you want to load this solution launching mkodt, you must launch :

    mkodt -s MyODT -B devenv=C:\Temp\MyModule.sln

    or :

    mkodt -s MyODT -B devenv=C:\Temp\MyModule.sln -b MyModule

NOTE : By default, if you give a solution file in the mkodt command line and if another solution is in the code\bin directory, it will be the solution of the command line that will be loaded in VC7.

WARNING : If you save a solution file in the code\bin directory or in another directory, the executable options given in the ODT are saved.

So, if you want to debug another ODT that launch the same executable, you must move or remove the solution file to take in account new options of the executable.

[Top]

Changing the Output Directory

To change the output directory, there are two possibilities:

use the -o mkodt's options:

Created directories:

set the ADL_ODT_OUT variable before running mkodt:

Created directories:

If ADL_ODT_OUT is not set or if users don't use the -o option, the output directory is: WSROOT/FW.tst/FunctionTests/Output/$OS. If the workspace is read-only, the output will be saved in ADL_ODT_TMP.

Example:

In this example, we replayed ODTs DRW*Rec* in frameworks Drafting*.tst in the CXR4rel level; mkodt found 524 ODTs; Furthermore, there is no option -o in the command line and the ADL_ODT_OUT is not set, so the mkodt ouput's will be sqved in ADL_ODT_TMP\MKODT_save_297. The command had been interrupted by user (^C).

[Top]

Using Other Options: -q, -X, -html, -xml, -l, -L

These options are used to modify the output of the mkodt command (-q, -X) or to give a list of ODT to replay (-L, -l):

Command Line	ODTs Replayed
mkodt -d E:\users\toto\MONWS -a -S -q -o E:\users\toto\output -b CNEXT (intel_a)	Replay all Switch ODTs of MONWS in quiet mode.
mkodt -d /u/users/toto\MONWS -s CCPCutRec -X -o E:\users\toto\output -b CNEXT -B dbx (aix_a)	The ODT CCPCutRec will be replayed and its output will be redirected on output screen in real time.
mkodt -d /u/users/toto\MONWS -s CCPCutRec -html -o E:\users\toto\output	The ODT CCPCutRec will be replayed and an html output will be created in E:\users\toto\output\ToolsData\TestAuto\mkodt\{OS}\mkodt_result.html
mkodt -d /u/users/toto\MONWS -s CCPCutRec -xml -o E:\users\toto\output	The ODT CCPCutRec will be replayed and an xml output will be created in E:\users\toto\output\fw.tst\FunctionTests\Output\{OS}\CCPCutRec.mkodt_result.xml It contains xml data like this : - <REPLAYRESULT> <WS name="MONWS" /> - <ODTRESULT rc="0" os="<OS>" pertinence="1" rundate="2004-01-15-11-15-57" elapsedtime="00:01"> <ODT name="CCPCutRec" fw="MyFw.tst" /> </ODTRESULT> </REPLAYRESULT>
mkodt -d /u/users/toto\MONWS -L /u/users/toto\MONWS/ FileListODT -X -o E:\users\toto\output -b CNEXT -B dbx (aix_a) or mkodt -d /u/users/toto\MONWS -L FileListODT -X -o E:\users\toto\output -b CNEXT -B dbx (aix_a) (if FileListODT is under the Workspace)	The file FileListODT contains the ODT list to replay; This file has the following format: FW1 TypeODT ODTName1 FW2 TypeODT ODTName2 ??
mkodt -d /u/users/toto\MONWS -s FileListFWODT -X -o E:\users\toto\output -b CNEXT -B dbx (aix_a) or mkodt -d /u/users/toto\MONWS -s FileListFWODT -X -o E:\users\toto\output -b CNEXT -B dbx (aix_a)	The file FileListFWODT contain the ODT list to replay; This file has the following format: ODTName1 ODTName2 ...

[Top]

History

Version: 1 [Jan 2000]	Document created
[Top]

Workspace where MONMOD is found	Workspaces where MYLIB can be loaded	Workspace where MYLIB is effectively loaded
WSDEV	WSDEV;WSPROJ;WSBSF	WSDEV
WSPROJ	WSPROJ;WSBSF	WSPROJ
WSBSF	WSBSF	WSBSF
WSDEV	WSPROJ;WSBSF	WSPROJ
WSPROJ	WSDEV;WSPROJ;WSBSF	WSPROJ
WSBSF	WSDEV;WSPROJ;WSBSF	WSBSF

RADE

C++ Unit Test Manager

Using mkodt

Abstract

Using SetOdtParam

Selecting the Operating System to Replay a Test Object

Modifying the Maximum Replay Time of a Test Object

Using WhichDir

Using ODTInit

Using mkodt Options

Using Basic Options

Using Concatenation Options (-p and -r)

Using -NOMaxTime Option

Using a Debugger

Changing the Output Directory

Using Other Options: -q, -X, -html, -xml, -l, -L

History