Update environment specific actions
Environment specific actions are preprocessing, run andpostprocessing. Actions delivered with the test environment template are considered as example have to be updated, usually. After selecting the Files tab below the edit window, provided actions are shown:
At least the run action requires some modification. Actions can be updated in the lower edit box of the window. When leaving the box, changes are saved to the file automatically. Here, the run action will be overloaded later in test cases. The example below shows a pattern for a typical run action as delivered with the test environment template.
The postprocessing action delivered as pattern provides a compare mechanism for comparing all files in the expected directory with test result files having the same name, which will be sufficient for the example. Usually, evaluating test results becomes a bit more difficult, since variable information as timestamps or file locations have to be eliminated from test results and expected data.
For the simple demonstration, action patterns need not to be updated. The run action will be overloaded later in test cases.
In order to support settings for environment variables, preprocessing actions have to be defined as function. The preprocessing file is included in the framework action testRun. The action patterns provided with the test environment pattern are listed below:
// preprocessing
#!/bin/bash
# define preprocessing action when required
preprocessing() {
# define environment variables required for tests, e.g.
export LD_LIBRARY_PATH=/usr/local/lib
}
// run
#!/bin/bash
source ${ROOT_DIR}/TestSuite.sh
# run test
# 1 - current test suite location in hierarchy
test_suite=$1 # CHAR
echo ${test_suite} started : $(date +'%Y/%m/%d %T') >>${LOGFILE_OUT}
cd ${WORK_AREA}/data
${BIN_DIR}\test.exe parm1 parm2
echo ${test_suite} finished: $(date +'%Y/%m/%d %T') >>${LOGFILE_OUT}
// postprocessing
#!/bin/bash
# source ${ROOT_DIR}/TestSuite.sh
# compare results ... a typical implementation
${TEST_ACT}/GetErrorsFromLog
cp -f ${WORK_AREA}/data/*.err ${TEST_RUN} 2>/dev/null
for x in ${WORK_AREA}/expected/*; do ${TEST_ACT}/Compare $x; done
// Compare
#!/bin/bash
# source ${ROOT_DIR}/TestSuite.sh
# 1 - file name (complete path) to be compared
echo "Compare $1"
diff -b "${WORK_AREA}/data/$(basename $1)" "$1" >>${COMPARE_OUT} 2> ${ERRORS_OUT} || ${TEST_ACT}/CopyFailed $1
// CopyFailed
#!/bin/bash
# copy files causing problems
# 1 - file name (complete path) to be copied
if [ ! -d ${TEST_RUN}/failed ] ; then
mkdir ${TEST_RUN}/failed
fi
cp "${WORK_AREA}/data/$(basename $1)" "${TEST_RUN}/failed/$(basename $1)"
echo "File ${TEST_RUN}/data/$(basename $1) missing or differs from expected result" >>${COMPARE_OUT}
The preprocessing action actually does nothing but has to be provided in the actions folder under main_suite. The binary/tools directory contains some Linux tools (diff, find etc.) for running the delivered postprocessing action. The action patterns provided with the test environment pattern are listed below:
// preprocessing.cmd
rem run pre-processing actions
rem in order to do something, the action has to be overwritten below
// run.cmd
rem Compile table
rem 1 - current test suite location in hierarchy
echo %1 started : %Date% %Time% >>%LOGFILE_OUT%
cd /D %WORK_AREA%\data
rem include test function call like %BIN_DIR%\test.exe parm1 parm2
echo %1 finished: %Date% %Time% >>%LOGFILE_OUT%
// postprocessing.cmd
rem compare results ... a typical implementation
copy /Y %WORK_AREA%\data\*.err %TEST_RUN%\. >nul
for %%x in ( %WORK_AREA%\expected\*.* ) do call %TEST_ACT%\Compare.cmd %%x
// Compare.cmd
rem 1 - file name (complete path) to be compared
%TOOLS_DIR%\diff "%WORK_AREA%\data\%~nx1" "%1" >>%COMPARE_OUT% 2>>%ERRORS_OUT% || call %TEST_ACT%\CopyFailed %1
// CopyFailed.cmd
rem 1 - file name (complete path) to be compared
%TOOLS_DIR%\diff "%WORK_AREA%\data\%~nx1" "%1" >>%COMPARE_OUT% 2>>%ERRORS_OUT% || call %TEST_ACT%\CopyFailed %1