https://www.stridewiki.com/api.php?action=feedcontributions&feedformat=atom&user=JaimegSTRIDE Wiki - User contributions [en]2026-04-28T04:34:08ZUser contributionsMediaWiki 1.39.10https://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8993Test Macros Sample2009-01-29T21:10:08Z<p>Jaimeg: /* Simple execution of all test units */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code (C and C++ implementations), and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test macros source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' For all C++ test versions, each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. Note there is only C++ implementation for this test.<br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to be bypassed.<br />
<br />
==Test Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test macros.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test macros is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test macros. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestMacros.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Macros initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Running Test Basic_Assert...<br />
Running Test Basic_CString...<br />
Running Test Basic_Comparison...<br />
Running Test Basic_ExpectBool...<br />
Running Test Basic_FloatingPt...<br />
Running Test Basic_Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 15<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 13 suites.<br />
***************************************************************************<br />
<br />
===Workspace-based Execution===<br />
<br />
TestMacros.ssw, a workspace in the TestMacros directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_MACRO_NAME''').Run();<br />
<br />
The '''TEST_MACRO_NAME''' is the name of the scl_test_macro test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_macro tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Units_Overview&diff=8992Test Units Overview2009-01-29T01:27:33Z<p>Jaimeg: /* ASSERT/EXPECT Macros */</p>
<hr />
<div>== Introduction ==<br />
<br />
STRIDE enables testing of C/C++ code through the use of xUnit-style test units. Test units can be written by developers, captured using an SCL pragma, and executed from the host. STRIDE facilitates the execution of some or all of the test units by automatically creating entry points for the execution of test units on the target. <br />
<br />
== Using test units ==<br />
<br />
=== Prerequisites ===<br />
<br />
see [[Desktop Installation#Third Party Components|Perl requirements]]. <br />
<br />
===How to get started (Overview)===<br />
<br />
The required steps to get started with writing test units are as follows:<br />
<br />
<ol><br />
<li>Create a new Studio workspace (or open an existing one).</li><br />
<li>Set the workspace to compile in C++ mode (In Studio, choose Tools->Settings->Compile as Cpp).</li><br />
<li>Write a test unit. You may create a C++ test class or a C test function as your test unit. Click '''[[Test_Units#Test_Unit_Requirements|here]]''' for more information on creating test units.</li><br />
To implement a test unit as a test class:<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int test1(void) { return 0;} // PASS<br />
int test2(void) { return 23;} // FAIL <>0<br />
};<br />
<br />
#pragma scl_test_class(Simple)<br />
</source><br />
Or, as a test function:<br />
<source lang=cpp><br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int test1(void) <br />
{<br />
return 0; // PASS<br />
}<br />
<br />
int test1(void) <br />
{<br />
return 23; // FAIL <>0<br />
}<br />
<br />
#pragma scl_test_flist("Simple", test1, test2)<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
<li>Compile the workspace & review the '''Simple''' interface in the Studio Interface tab</li><br />
<li>Create a script to generate the Intercept Module(IM) '''after''' the compilation step.<br />
:For the simple STUB generation required for test unit execution, you can use the following code</li><br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE qw(in);<br />
Win32::OLE->Option(Warn => 3);<br />
my $intercept = $main::studio->Workspace->Intercept; <br />
$intercept->{Path} = $main::studio->Workspace->Path;<br />
$intercept->{Name} = $main::studio->Workspace->Name;<br />
map {$intercept->Item($_)->{Stub} = 1} (0..($intercept->Count - 1));<br />
$intercept->Create(); <br />
</source><br />
<li>Optionally add custom scripts to automate the building and executing your application.</li><br />
<li>Ensure that the Studio workspace include path contains the location to all of your test unit declaration (header) files.</li><br />
<li>Once you have created one or more test units, ensure the following:<br />
:* Workspace is compiled and saved<br />
:* Intercept Module is generated (Stubs for all Test Units)<br />
:* Target application re-built<br />
:* Target application downloaded & started<br />
:* STRIDE Connected to Target<br />
</li><br />
<br />
<li>If your application is running, you can start executing test units.<br />
:* You can test-execute individual test units interactively using the '''Studio interface''' view. To do this, open the user interface view corresponding to the test unit you would like to execute, then call it. The return values will indicate how many tests produced each of four (4) result types. Furthermore, the input to the entry point will allow you to select all methods for execution (the default) or individual methods via a dropdown list of enumerated values.<br />
:* Once you are confident that the test units are behaving as expected, you can generate one or more execution scripts using the '''Script Wizard'''. Sample '''[[templates]]''' for executing test unit entry points are provided in the %STRIDE_DIR%\templates\Script Wizard directory.<br />
:* When writing scripts to execute test units, the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection is a powerful tool for test unit execution and reporting, and for obtaining test results.</li><br />
<li>For integration with larger regression test workspaces, we recommend that developers check in their test unit code and, optionally, the template-generated scripts that can be used to execute their test units.</li><br />
</ol><br />
<br />
===Pragmas for Test Units===<br />
STRIDE supports three pragmas for capturing and qualifying test units: <br />
<br />
*'''<code>scl_test_class ( class-name )</code>''': Declares a test class as captured. Once captured, STRIDE will generate the appropriate code for executing the test methods in the class. See the [[scl_test_class|scl_test_class page]] for more information.<br />
*'''<code>scl_test_flist ( test-unit-name , test-function-name { , test-function-name } )</code>''': Declares a test unit as captured, by the specified test-unit-name. One or more functions (test methods) are associated with the test unit. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_flist|scl_test_flist page]] for more information.<br />
*'''<code>scl_test_cclass ( struct-name , init-function-name { , deinit-function-name } )</code>''': Declares a test unit as captured. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_cclass|scl_test_cclass page]] for more information.<br />
*'''<code>scl_test_setup ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a setup fixture for the test unit. If specified, the setup method will be called before the execution of each test method. See the [[scl_test_setup|scl_test_setup page]] for more information.<br />
*'''<code>scl_test_teardown ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a teardown fixture for the test unit. If specified, the teardown method will be called after the execution of each test method. See the [[scl_test_teardown|scl_test_teardown page]] for more information.<br />
<br />
== Test Unit Requirements ==<br />
<br />
Several variations on typical xUnit-style test units are supported. The additional supported features include: <br />
<br />
*Test status can be set using STRIDE Runtime APIs ''or'' by specifying simple return types for test methods. <br />
*Simple return types: 0 = PASS; &lt;&gt; 0 = FAIL <br />
*void return type with no explict status setting is assumed PASS <br />
*Test writers can create additional child suites and tests at runtime by using Runtime APIs. <br />
*We do not rely on exceptions for reporting of status.<br />
<br />
The STRIDE test class framework has the following requirements of each test class: <br />
<br />
*The test class must have a suitable default (no-argument) constructor. <br />
*The test class must have one or more public methods suitable as test methods. Allowable test methods always take no arguments (void) and return either void or simple integer types (int, short, long, char or bool). At this time, we do not allow typedef types or macros for the return values specification. <br />
*the scl_test_class pragma must be applied to the class.<br />
<br />
<br />
=== Simple example using return values for status ===<br />
==== Using a Test Class ====<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int tc_Int_ExpectPass(void) {return 0;}<br />
int tc_Int_ExpectFail(void) {return -1;}<br />
bool tc_Bool_ExpectPass(void) {return true;}<br />
bool tc_Bool_ExpectFail(void) {return false;}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(Simple)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int tf_Int_ExpectPass(void) {return 0;}<br />
int tf_Int_ExpectFail(void) {return -1;}<br />
bool tf_Bool_ExpectPass(void) {return true;}<br />
bool tf_Bool_ExpectFail(void) {return false;}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("Simple", tf_Int_ExpectPass, tf_Int_ExpectFail, tf_Bool_ExpectPass, tf_Bool_ExpectFail)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using runtime test service APIs ===<br />
==== Using a Test Class ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class RuntimeServices_basic {<br />
public: <br />
void tc_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(RuntimeServices_basic)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
void tf_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tf_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tf_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("RuntimeServices_basic", tf_ExpectPass, tf_ExpectFail, tf_ExpectInProgress)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using srTest base class ===<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class MyTest : public stride::srTest {<br />
public:<br />
void tc_ExpectPass(void) <br />
{<br />
testCase.AddComment("this test should pass");<br />
testCase.SetStatus(srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
testCase.AddComment("this test should fail");<br />
testCase.SetStatus(srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
testCase.AddComment("this test should be in progress");<br />
}<br />
int tc_ChangeMyName(void) <br />
{<br />
testCase.AddComment("this test should have name = MyChangedName");<br />
testCase.SetName("MyChangedName");<br />
return 0;<br />
}<br />
int tc_ChangeMyDescription(void) <br />
{<br />
testCase.AddComment("this test should have a description set");<br />
testCase.SetDescription("this is my new description");<br />
return 0;<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(MyTest)<br />
#endif<br />
</source><br />
<br />
== Runtime Test Services ==<br />
<br />
The Runtime Test Services (declared in srTest.h) are a set of APIs in the STRIDE Runtime that facilitate the writing of target based test code. These APIs make up an optional portion of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. These APIs also allow target test code to create additional test suites and test cases dynamically at runtime. <br />
<br />
There are 2 alternate ways of accessing these APIs: through C-based functions, or through a C++ base class from which you may derive your C++ test class. These are discussed below in C Test Functions, and C++ Test Classes sections below.<br />
<br />
=== C Test Functions ===<br />
<br />
The following C APIs are provided: <br />
<br />
*'''[[#srTestSuiteAddSuite|srTestSuiteAddSuite]]''': creates an additional sub-suite at runtime. <br />
*'''[[#srTestSuiteSetName|srTestSuiteSetName]]''': sets the name of the specified suite. <br />
*'''[[#srTestSuiteSetDescription|srTestSuiteSetDescription]]''': sets the description of the specified suite. <br />
*'''[[#srTestSuiteAddTest|srTestSuiteAddTest]]''': creates an additional test case at runtime. <br />
*'''[[#srTestCaseSetName|srTestCaseSetName]]''': sets the name of the specified test case. <br />
*'''[[#srTestCaseSetDescription|srTestCaseSetDescription]]''': sets the description of the specified test case. <br />
*'''[[#srTestCaseAddComment|srTestCaseAddComment]]''': adds a comment to the specified test case. <br />
*'''[[#srTestCaseSetStatus|srTestCaseSetStatus]]''': explicitly sets the status for the specified test case.<br />
*'''[[#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]]''': creates an annotation at runtime. <br />
*'''[[#srTestAnnotationAddComment|srTestAnnotationAddComment]]''': adds a comment to the specified annotation.<br />
<br />
<br />
==== srTestSuiteAddSuite ====<br />
The srTestSuiteAddSuite() routine is used to add a new test suite to the specified test suite.<br />
<source lang=c><br />
srTestSuiteHandle_t srTestSuiteAddSuite(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test suite is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test suite. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
|srTestSuiteHandle_t <br />
| Handle of the newly created test suite. srTEST_SUITE_INVALID indicates failure to create test suite.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addSuite(void)<br />
{<br />
srTestSuiteHandle_t subSuite =<br />
srTestSuiteAddSuite(srTEST_SUITE_DEFAULT, "tf Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addSuite)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetName ====<br />
The srTestSuiteSetName() routine is used to set the name of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetName(srTestSuiteHandle_t tTestSuite, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_setName(void)<br />
{<br />
srTestSuiteSetName(srTEST_SUITE_DEFAULT, "Setting name for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetDescription ====<br />
The srTestSuiteSetDescription() routine is used to set the description of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetDescription(srTestSuiteHandle_t tTestSuite, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include "srtest.h"<br />
void tfsuite_setDescription(void)<br />
{<br />
srTestSuiteSetDescription(srTEST_SUITE_DEFAULT,<br />
"Setting description for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddTest ====<br />
The srTestSuiteAddTest() routine is used to add a new test case to the specified test suite.<br />
<source lang=c><br />
srTestCaseHandle_t srTestSuiteAddTest(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test case is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test case. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCaseHandle_t <br />
| Handle of the newly created test case. srTEST_CASE_INVALID indicates failure to create test case.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
void tfsuite_addTest(void)<br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "dynamic test case %d", count);<br />
srTestCaseHandle_t test = srTestSuiteAddTest(srTEST_SUITE_DEFAULT, szName);<br />
srTEST_ADD_COMMENT_WITH_LOCATION(test, "this is a dynamic test case");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addTest)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetName ====<br />
The srTestCaseSetName() routine is used to set set the name of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetName(srTestCaseHandle_t tTestCase, const srCHAR *szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setName(void)<br />
{<br />
srTestCaseSetName(srTEST_CASE_DEFAULT, "Setting name for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetDescription ====<br />
The srTestCaseSetDescription() routine is used to set the description of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetDescription(srTestCaseHandle_t tTestCase, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setDescription(void)<br />
{<br />
srTestCaseSetDescription(srTEST_CASE_DEFAULT,<br />
"Setting description for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseAddComment ====<br />
The srTestCaseAddComment() routine is used to add a comment (aka a log) to be reported with the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseAddComment(srTestCaseHandle_t tTestCase, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_addComment(void)<br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_addComment)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatus ====<br />
The srTestCaseSetStatus() routine is used to set the result of test case.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input <br />
| The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatus(void)<br />
{<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatus)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatusEx ====<br />
The srTestCaseSetStatusEx() routine is used to set the result of test case and allow specification of an extendedFailureCode.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration, srLONG lExtendedFailureCode)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test. dwDuration Input The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|-<br />
| lExtendedFailureCode <br />
| Input <br />
| The Stride framework uses the extendedFailureCode to capture the numeric results of test method when the test method fails via a numeric (non-void, nonbool) return type.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatusEx(void)<br />
{<br />
srTestCaseSetStatusEx(srTEST_CASE_DEFAULT, srTEST_FAIL, 0, -5);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatusEx)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddAnnotation ====<br />
The srTestSuiteAddAnnotation() routine is used to add a new annotation to the specified test suite.<br />
<source lang=c><br />
srTestAnnotationHandle_t srTestSuiteAddAnnotation(rTestSuiteHandle_t tParent, srTestAnnotationLevel_e eLevel, const srCHAR * szName, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new annotation is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| eLevel<br />
| Input <br />
| Annotation level. Cannot be empty.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of annotation. If null, the default host naming scheme will be used.<br />
|-<br />
| szDescr<br />
| Input <br />
| Pointer to a null-terminated string representing the description of annotation. If null, description will be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotationHandle_t <br />
| HHandle of the newly created annotation. srTEST_ANNOTATION_INVALID indicates failure to create annotation.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addAnnotation(void) <br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "annotation %d", count);<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
szName,<br />
"description of annotation");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addAnnotation)<br />
#endif<br />
</source><br />
<br />
==== srTestAnnotationAddComment ====<br />
The srTestAnnotationAddComment() routine is used to add a comment (aka a log) to be reported with the specified annotation.<br />
<source lang=c><br />
srWORD srTestAnnotationAddComment(srTestAnnotationHandle_t tTestAnnotation, const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestAnnotation<br />
| Input<br />
| Handle to an annotation created using srTestSuiteAddAnnotation.<br />
|-<br />
| szLabel<br />
| Input <br />
| Pointer to a null-terminated string for the label. If null, the default label will be applied.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuiteAnnotation_addComment(void) <br />
{<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
“annot”,<br />
“annot description”);<br />
srTestAnnotationAddComment(annot,<br />
srNULL,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuiteAnnotation_addComment)<br />
#endif<br />
</source><br />
<br />
=== C++ Test Classes ===<br />
The Runtime Test Services C APIs work equally well from C test functions and C++ test classes. If, however, you are using C++ it might be more convinient for you to derive your C++ test classes from the Runtime Test Services C++ base class, ''srTest''. That way you will have access to a set of simpler to use C++ classes. <br />
<br />
The following C++ classes are provided: <br />
* '''[[#class srTest|class srTest]]''' - base test class<br />
* '''[[#class srTestSuite|class srTestSuite]]''' - represents a test suite<br />
* '''[[#class srTestCase|class srTestCase]]''' - represents a test case<br />
* '''[[#class srTestAnnotation|class srTestAnnotation]]''' - represents a test annotation<br />
<br />
==== class srTest ====<br />
The srTest class provides two Member Objects:<br />
*''testSuite'' of class srTestSuite <br />
*''testCase''of class srTestCase<br />
<br />
==== class srTestSuite ====<br />
The srTest class provides the folowing methods:<br />
<br />
===== method AddSuite =====<br />
The AddSuite method is used to add a new test suite.<br />
<source lang=cpp><br />
srTestSuite AddSuite(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
|szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test suite. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestSuite <br />
| Newly created test suite class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
stride::srTestSuite suite = testSuite.AddSuite("tc Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test suite.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetName(void);<br />
};<br />
<br />
void srtest_class::suiteSetName(void)<br />
{<br />
testSuite.SetName("Setting name for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test suite.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|- <br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetDescription(void);<br />
};<br />
<br />
void srtest_class::suiteSetDescription(void)<br />
{<br />
testSuite.SetDescription("Setting description for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddTest =====<br />
The AddTest method is used to add a new test case to test suite.<br />
<source lang=cpp><br />
srTestCase AddTest(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test case. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCase <br />
| Newly created test case class.<br />
|}<br />
<br><br />
'''Example'''<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
const std::string prefix("dynamic test case ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strm;<br />
strm << prefix << count;<br />
stride::srTestCase tc = testSuite.AddTest(strm.str().c_str());<br />
tc.AddComment("this is a dynamic test case");<br />
tc.SetStatus(srTEST_PASS);<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddAnnotation =====<br />
The AddAnnotation method is used to add a new annotation to test suite.<br />
<source lang=cpp><br />
srTestAnnoation AddAnnotation(srTestAnnotationLevel_e eLevel, const srCHAR * szName = srNULL, const srCHAR * szDescr = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eLevel<br />
| Input<br />
| Annotation level. Cannot be empty.<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of annotation. If empty, the default host naming scheme will be used.<br />
|- <br />
| szDescr<br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the description of annotation. If empty, the description will be blank.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotation<br />
| Newly created annotation class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddAnnotation(void);<br />
};<br />
<br />
void srtest_class::suiteAddAnnotation(void) <br />
{<br />
const std::string prefixName("annotation ");<br />
const std::string prefixDescr("description of annotation ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strmName;<br />
std::stringstream strmDescr;<br />
strmName << prefixName << count;<br />
strmDescr << prefixDescr << count;<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
strmName.str().c_str(),<br />
strmDescr.str().c_str());<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestCase ====<br />
The srTestCase class provides the following methods:<br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test case.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetName(void);<br />
};<br />
<br />
void srtest_class::caseSetName(void)<br />
{<br />
testCase.SetName("Setting name for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test case.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetDescription(void);<br />
};<br />
<br />
void srtest_class::caseSetDescription(void)<br />
{<br />
testCase.SetDescription("Setting description for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to test case.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseAddComment(void);<br />
};<br />
<br />
void srtest_class::caseAddComment(void)<br />
{<br />
testCase.AddComment("this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetStatus =====<br />
The SetStatus method is used to set the result of the default test case.<br />
<source lang=cpp><br />
srWORD SetStatus(srTestStatus_e eStatus, srDWORD dwDuration = 0)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input (Optional)<br />
| The duration of the test in clock ticks. The default is 0.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetStatus(void);<br />
};<br />
<br />
void srtest_class::caseSetStatus(void)<br />
{<br />
testCase.SetStatus(srTEST_INPROGRESS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestAnnotation ====<br />
The srTestAnnotation class provides the following methods:<br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to an annotation created under a test suite.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szLabel<br />
| Input <br />
| Pointer to null-terminated string for the label. If null, the default label will be applied.<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAnnotationAddComment(void);<br />
};<br />
<br />
void srtest_class::suiteAnnotationAddComment(void)<br />
{<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
“annot”,<br />
“annot description”);<br />
ta.AddComment("this comment on annotation should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
Refer to the [[Media:s2sSCLReferenceGuide.pdf|SCL Reference Guide]] or the [[Media:s2sRuntime.pdf|Runtime Developer's Guide]] for detailed information about any of these APIs.<br />
<br />
== ASSERT/EXPECT Macros ==<br />
<br />
The STRIDE Test Unit implementation also provides a set of Test Macros available for use within test methods. The macros are optional - you are not required to use them in your test units. They provide shortcuts for testing assertions and automatic report annotation in the case of failures. <br />
<br />
The macros can be used in C++ and C test unit code (Note that there is no C version of exceptions test). <br />
<br />
=== General guidelines for all macros ===<br />
<br />
srEXPECT_xx macros will set the current test case to fail (if it hasn’t already been set) and produce an annotation in the report if the expectation fails. If the expectation succeeds, there is no action. <br />
<br />
srASSERT_xx macros will set the current test case to fail (if it hasn’t already been set) and insert an annotation into the report if the assertion fails. In addition, a return from the current function will occur. srASSERT_xx macros can only be used in test functions which return void. If the assertion succeeds there is no action. <br />
<br />
The report annotation produced by a failed macro always includes the source file and line along with details about the condition that failed and the failing values. <br />
<br />
=== Boolean Macros ===<br />
The boolean macros take a single condition expression, ''cond'', that evaluates to an integral type or bool. The condition will be evaluated once. if ''cond'' evaluates to non-zero the assertion or expectation fails. When a failure occurs the report will be annotated. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE(''cond'');<br />
| srASSERT_TRUE(''cond'');<br />
| ''cond'' is true<br />
<br />
|-<br />
| srEXPECT_FALSE(''cond'');<br />
| srASSERT_FALSE(''cond'');<br />
| ''cond'' is false<br />
<br />
|}<br />
<br />
=== Comparison Macros ===<br />
<br />
Comparison macros take two operands and compare them using the indicated operator. The comparison macros will work for primitive types as well as objects that have the corresponding comparison operator implemented. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ(''val1'', ''val2'');<br />
| srASSERT_EQ(''val1'', ''val2'');<br />
| ''val1'' == ''val2''<br />
<br />
|-<br />
| srEXPECT_NE(''val1'', ''val2'');<br />
| srASSERT_NE(''val1'', ''val2'');<br />
| ''val1'' != ''val2''<br />
<br />
|-<br />
| srEXPECT_LT(''val1'', ''val2'');<br />
| srASSERT_LT(''val1'', ''val2'');<br />
| ''val1''<nowiki> < </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_LE(''val1'', ''val2'');<br />
| srASSERT_LE(''val1'', ''val2'');<br />
| ''val1''<nowiki> <= </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_GT(''val1'', ''val2'');<br />
| srASSERT_GT(''val1'', ''val2'');<br />
| ''val1'' > ''val2''<br />
<br />
|-<br />
| srEXPECT_GE(''val1'', ''val2'');<br />
| srASSERT_GE(''val1'', ''val2'');<br />
| ''val1'' >= ''val2''<br />
<br />
|}<br />
<br />
=== C String Comparison Macros ===<br />
<br />
C String Comparison Macros are intended only for use with C-style zero terminated strings. The strings can be char or wchar_t based. In particular, these macros should not be used for object of one or other string class, since such classes have overloaded comparison operators. The standard comparison macros should be used instead. <br />
<br />
* The length of a string displayed in the report annotation message is controllable via the following macro: srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY (found in srtestmacros.h). If a string value is truncated because of the length limit, the text "...(trunc)" will always appear next to it. <br />
* An empty string will appear in error message output as “”. A null string will appear as NULL with no surrounding quotes. Otherwise all output strings are quoted. <br />
* The type of str1 and str2 must be compatible with const char* or const wchar_t*. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ(''str1'', ''str2'');<br />
| srASSERT_STREQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content<br />
<br />
|-<br />
| srEXPECT_STRNE(''str1'', ''str2'');<br />
| srASSERT_STRNE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ(''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content, ignoring case.<br />
<br />
|-<br />
| srEXPECT_STRCASENE(''str1'', ''str2'');<br />
| srASSERT_STRCASENE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content, ignoring case.<br />
<br />
|}<br />
<br />
=== Exception Macros ===<br />
Exception macros are used to ensure that expected exceptions are thrown. They require exception support from the target compiler. If the target compiler does not have exception support the macros cannot be used and must be disabled. The support can be disabled via the macro srCFG_TEST_MACROS_EXCEPTIONS_ON found in srtestmacros.h.<br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW(statement, ex_type);<br />
| srASSERT_THROW(statement, ex_type);<br />
| ''statement'' throws an exception of type ''ex_type''<br />
<br />
|-<br />
| srEXPECT_THROW_ANY(''statement'');<br />
| srASSERT_THROW_ANY(''statement'');<br />
| ''statement'' throws an exception (type not important)<br />
<br />
|-<br />
| srEXPECT_NO_THROW(''statement'');<br />
| srASSERT_NO_THROW(''statement'');<br />
| ''statement'' does not throw an exception<br />
<br />
|}<br />
<br />
=== Predicate Macros ===<br />
Predicate macros allow user control over the pass/fail decision making in a macro. A predicate is a function returning bool that is implemented by the user but passed to the macro. Other arguments for the predicate are also passed to the macro. The macros allow for predicate functions with up to four parameters. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1(''pred'', ''val1'')<br />
| srASSERT_PRED1(''pred'', ''val1'')<br />
| ''pred''(''val1'') returns true<br />
<br />
|-<br />
| srEXPECT_PRED2(''pred'', ''val1'', ''val2'')<br />
| srASSERT_PRED2(''pred'', ''val1'', ''val2'')<br />
| ''pred''(''val1'', ''val2'') returns true<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
| <br />
<br />
|}<br />
All predicate macros require a predicate function function which returns bool. The predicate macros allow functions with one to 4 parameters. Following are the report annotations resulting from expectation or assertion failures.<br />
<br />
=== Floating Point Macros ===<br />
Floating point macros are for comparing equivalence (or near equivalence) of floating point numbers. These macros are necessary since because equivalence comparisons for floating point numbers will often fail due to round-off errors. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Floating Point Macros'''<br />
<br />
|-<br />
| srEXPECT_NEAR(val1, val2, epsilon);<br />
| srASSERT_NEAR(val1, val2, epsilon);<br />
| The absolute value of the difference between val1 and val2 is epsilon.<br />
|}<br />
<br />
=== Dynamic Test Case Macros ===<br />
The macros presented so far are not capable of dealing with dynamic test cases. In order to handle dynamic test cases, each of the macros requires another parameter which is the test case to report against. Other than this, these macros provide exactly equivalent functionality to the non-dynamic peer. The dynamic macros are listed below. All require a test case, value of type srTestCaseHandle_t from srtest.h, to be passed as the first parameter).<br />
<br />
{| class="prettytable"<br />
| '''''Nonfatal assertion'''''<br />
| '''''Fatal Assertion'''''<br />
<br />
|-<br />
| colspan="2" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE_DYN(tc, ''cond'');<br />
| srASSERT_TRUE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| srEXPECT_FALSE_DYN(tc, ''cond'');<br />
| srASSERT_FALSE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| colspan="2" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_EQ_DYN(tc, ''expect'', ''val'');<br />
<br />
|-<br />
| srEXPECT_NE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_NE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| colspan="2" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| colspan="2" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW_DYN(statement, ex_type);<br />
| srASSERT_THROW_DYN(tc, statement, ex_type);<br />
<br />
|-<br />
| srEXPECT_THROW_ANY_DYN(tc, ''statement'');<br />
| srASSERT_THROW_ANY_DYN(tc, ''statement'');<br />
<br />
|-<br />
| srEXPECT_NO_THROW_DYN(tc, ''statement'');<br />
| srASSERT_NO_THROW_DYN(tc, ''statement'');<br />
<br />
|-<br />
| colspan="2" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
| srASSERT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
<br />
|-<br />
| srEXPECT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
| srASSERT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
<br />
|-<br />
| colspan="2" | '''Floating Point'''<br />
<br />
|-<br />
| srEXPECT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
| srASSERT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
<br />
|}<br />
<br />
=== Overloading The << operator for report annotation (C++ tests only) ===<br />
<br />
<nowiki>All the macros support the adding to the report annotations using the << operator. For example:</nowiki><br />
<br />
srEXPECT_TRUE( a != <nowiki>b) << “My custom message”; </nowiki><br />
<br />
<nowiki>As delivered, the macros will support stream operator annotations using all the numeric types, char* and s2String. The user may create custom types to be used a report annotation by providing an implementation of the << operator for their custom type. </nowiki><br />
<br />
<nowiki>The user of the asserting macros package may overload the << operator in order to annotate reports using a custom class. An example is below. </nowiki><br />
<br />
<nowiki>The following will compile and execute successfully given that the << operator is overloaded as shown:</nowiki><br />
<br />
<pre><br />
MyCustomClass custom(34); <br />
<br />
srEXPECT_FALSE(true) << custom;<br />
<br />
// MyCustomClass implementation<br />
class MyCustomClass<br />
{<br />
public:<br />
MyCustomClass(int i) : m_int(i) {}<br />
<br />
private: <br />
int m_int; <br />
friend stride::Message& operator<< <br />
( stride::Message& ss, const MyCustomClass& obj);<br />
}; <br />
<br />
stride::Message& operator<<(stride::Message& ss, const MyCustomClass& obj)<br />
{<br />
<br />
// format the internals as a string and send on<br />
char buf[20]; <br />
sprintf(buf, "%d", obj.m_int); <br />
ss << buf;<br />
return ss;<br />
}<br />
</pre><br />
<br />
== Scripting a Test Unit ==<br />
<br />
To automate the execution and reporting of a Test Unit a script is required. Scripts can be written by hand or automatically generated using the Script Wizard and a corresponding template script. A scripting tool for executing a test unit is the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection. An [[AutoScript#ascript.TestUnits.Item|Ascript TestUnit]] object assembles all of the reporting information for the test unit and its corresponding test methods. <br />
<br />
*Require usage of the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection <br />
*Can be written by hand (refer below) <br />
*Can leverage [[Templates|Templates]] via the Script Wizard <br />
*Order of multiple test units dictated by SUID assignment<br />
<br />
<br> <br />
<br />
=== JScript example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=javascript><br />
// Ensure test unit exists<br />
if (ascript.TestUnits.Item("Simple") != null) <br />
ascript.TestUnits.Item("Simple").Run();<br />
</source><br />
<br />
=== Perl example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
my $tu = $main::ascript->TestUnits->Item("Simple");<br />
if (defined $tu) {<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
=== JScript example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=javascript><br />
var Units = ["Simple1","Simple2"];<br />
<br />
// iterate through each function<br />
for (i in Units)<br />
{<br />
var tu = ascript.TestUnits.Item(Units[i]);<br />
if ( tu&nbsp;!= null ) <br />
tu.Run();<br />
}<br />
</source><br />
<br />
=== Perl example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
# initialize an array with all selected function names<br />
my @UnitNames = ("Simple1","Simple2");<br />
foreach (@UnitNames) { <br />
my $tu = $main::ascript->TestUnits->Item($_->[1]);<br />
die "TestUnit not found: $_->[1]\n" unless (defined $tu);<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
[[Category:Test Units]]<br />
[[Category:Reference]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8991Test Macros Sample2009-01-29T00:42:35Z<p>Jaimeg: </p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code (C and C++ implementations), and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test macros source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' For all C++ test versions, each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. Note there is only C++ implementation for this test.<br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to be bypassed.<br />
<br />
==Test Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test macros.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test macros is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test macros. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestMacros.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Macros initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 15<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 15 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestMacros.ssw, a workspace in the TestMacros directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_MACRO_NAME''').Run();<br />
<br />
The '''TEST_MACRO_NAME''' is the name of the scl_test_macro test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_macro tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8990Test Macros Sample2009-01-29T00:41:45Z<p>Jaimeg: /* Run Individual */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code (C and C++ implementations), and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test macros source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' For all C++ test versions, each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. Note there is only C++ implementation for this test.<br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to be bypassed.<br />
<br />
==Test Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test macros.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test macros is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test macros. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestMacros.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Macros initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 15<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 15 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestMacros.ssw, a workspace in the TestMacros directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_MACRO_NAME''').Run();<br />
<br />
The '''TEST_MACRO_NAME''' is the name of the scl_test_macro test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_macro tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8989Test Macros Sample2009-01-29T00:37:11Z<p>Jaimeg: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code (C and C++ implementations), and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test macros source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' For all C++ test versions, each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. Note there is only C++ implementation for this test.<br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to be bypassed.<br />
<br />
==Test Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test macros.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test macros is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test macros. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestMacros.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Macros initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 15<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 15 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestMacros.ssw, a workspace in the TestMacros directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_MACRO_NAME''' is the name of the scl_test_macro test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_macro tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8988Test Macros Sample2009-01-29T00:36:00Z<p>Jaimeg: /* Test Class Macros Execution */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code, and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test macros source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' For all C++ test versions, each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. Note there is only C++ implementation for this test.<br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to be bypassed.<br />
<br />
==Test Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test macros.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test macros is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test macros. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestMacros.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Macros initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestMacros\TestMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 15<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 15 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestMacros.ssw, a workspace in the TestMacros directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_MACRO_NAME''' is the name of the scl_test_macro test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_macro tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8987Test Macros Sample2009-01-29T00:07:27Z<p>Jaimeg: /* Sample Test Class Macros */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code, and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test macros source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' For all C++ test versions, each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. Note there is only C++ implementation for this test.<br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to be bypassed.<br />
<br />
==Test Class Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test classes is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test classes. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestClassMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Class initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClassMacros\TestClassMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClassMacros\TestClassMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 7<br />
Failed: 8<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestClassMacros.ssw, a workspace in the TestClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestClassMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_Class_NAME''' is the name of the scl_test_class test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_class tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8986Test Macros Sample2009-01-28T23:43:57Z<p>Jaimeg: /* Getting Started */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code, and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestMacros.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestMacros.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Class Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test class source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. <br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to by bypassed.<br />
<br />
==Test Class Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test classes is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test classes. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestClassMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Class initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClassMacros\TestClassMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClassMacros\TestClassMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 7<br />
Failed: 8<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestClassMacros.ssw, a workspace in the TestClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestClassMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_Class_NAME''' is the name of the scl_test_class test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_class tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Macros_Sample&diff=8985Test Macros Sample2009-01-28T23:36:29Z<p>Jaimeg: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
The Test Macros Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestMacros</tt>'''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample test macros source code, and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestClass.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestClass.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Class Macros==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test class source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' each of the example test classes is grouped in the ''Basic'' namespace. This is for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover simple uses of each of the macro families. The names of the test methods contain either ''Pass'' or ''Fail''. All methods containing ''Fail'' illustrates uses of test macros that result in failures. Methods containing ''Pass'' illustrate passing uses. <br />
<br />
====01_01_Basic_ExpectBool====<br />
<br />
This example demonstrates uses of the [[Test_Units#Boolean_Macros|''srEXPECT_TRUE()'' and ''srEXPECT_FALSE()'']] test class macros. <br />
<br />
====01_02_Basic_Comparison====<br />
<br />
This example demonstrates uses of the [[Test_Units#Comparison_Macros|''srEXPECT_EQ()'', ''srEXPECT_NE()'', ''srEXPECT_GT()'', ''srEXPECT_GE()'', ''srEXPECT_LT()'' and ''srEXPECT_LE()'']] macros. <br />
<br />
====01_03_Basic_CString====<br />
<br />
This example demonstrates use of the C-string (zero terminated character sequence) macros [[Test_Units#C_String_Comparison_Macros|''srEXPECT_STREQ()'', ''srEXPECT_STRNE(''), ''srEXPECT_STRCASEEQ()'' and ''srEXPECT_STRCASENE()'']]. <br />
<br />
====01_04_Basic_Exceptions====<br />
<br />
This example demonstrates use of the exception verification macros [[Test_Units#Exception_Macros|''srEXPECT_THROW()'', ''srEXPECT_THROW_ANY()'' and ''srEXPECT_NO_THROW()'']]. <br />
<br />
====01_05_Basic_Predicates====<br />
<br />
This example demonstrates use of the predicate based macros [[Test_Units#Predicate_Macros|''srEXPECT_PRED<n>()'']].<br />
<br />
====01_06_Basic_FloatingPt====<br />
<br />
This example demonstrates use of the macro used to test equality (or near equality) of floating point values [[Test_Units#Floating_Point_Macros|''srEXPECT_NEAR()'']].<br />
<br />
====01_07_Basic_Assert====<br />
<br />
This example illustrates the use of the [[Test_Units#General_guidelines_for_all_macros|assertion macros]] (''srASSERT_xx'') which, in contrast to the [[Test_Units#General_guidelines_for_all_macros|expectation macros]] (''srEXPECT_xx''), cause the rest of the test case code to by bypassed.<br />
<br />
==Test Class Macros Execution==<br />
<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test classes is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test classes. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestClassMacros.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Class initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Assert...<br />
Running Test Basic::CString...<br />
Running Test Basic::Comparison...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::ExpectBool...<br />
Running Test Basic::FloatingPt...<br />
Running Test Basic::Predicates...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClassMacros\TestClassMacros.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClassMacros\TestClassMacros.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 7<br />
Failed: 8<br />
In Progress: 0<br />
Not Applicable: 0<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
<br />
===Workspace-based Execution===<br />
<br />
TestClassMacros.ssw, a workspace in the TestClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestClassMacros.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alphabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_Class_NAME''' is the name of the scl_test_class test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_class tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Units_Overview&diff=8965Test Units Overview2009-01-23T02:20:28Z<p>Jaimeg: /* Scripting a Test Unit */</p>
<hr />
<div>== Introduction ==<br />
<br />
STRIDE enables testing of C/C++ code through the use of xUnit-style test units. Test units can be written by developers, captured using an SCL pragma, and executed from the host. STRIDE facilitates the execution of some or all of the test units by automatically creating entry points for the execution of test units on the target. <br />
<br />
== Using test units ==<br />
<br />
=== Prerequisites ===<br />
<br />
see [[Desktop Installation#Third Party Components|Perl requirements]]. <br />
<br />
===How to get started (Overview)===<br />
<br />
The required steps to get started with writing test units are as follows:<br />
<br />
<ol><br />
<li>Create a new Studio workspace (or open an existing one).</li><br />
<li>Set the workspace to compile in C++ mode (In Studio, choose Tools->Settings->Compile as Cpp).</li><br />
<li>Write a test unit. You may create a C++ test class or a C test function as your test unit. Click '''[[Test_Units#Test_Unit_Requirements|here]]''' for more information on creating test units.</li><br />
To implement a test unit as a test class:<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int test1(void) { return 0;} // PASS<br />
int test2(void) { return 23;} // FAIL <>0<br />
};<br />
<br />
#pragma scl_test_class(Simple)<br />
</source><br />
Or, as a test function:<br />
<source lang=cpp><br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int test1(void) <br />
{<br />
return 0; // PASS<br />
}<br />
<br />
int test1(void) <br />
{<br />
return 23; // FAIL <>0<br />
}<br />
<br />
#pragma scl_test_flist("Simple", test1, test2)<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
<li>Compile the workspace & review the '''Simple''' interface in the Studio Interface tab</li><br />
<li>Create a script to generate the Intercept Module(IM) '''after''' the compilation step.<br />
:For the simple STUB generation required for test unit execution, you can use the following code</li><br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE qw(in);<br />
Win32::OLE->Option(Warn => 3);<br />
my $intercept = $main::studio->Workspace->Intercept; <br />
$intercept->{Path} = $main::studio->Workspace->Path;<br />
$intercept->{Name} = $main::studio->Workspace->Name;<br />
map {$intercept->Item($_)->{Stub} = 1} (0..($intercept->Count - 1));<br />
$intercept->Create(); <br />
</source><br />
<li>Optionally add custom scripts to automate the building and executing your application.</li><br />
<li>Ensure that the Studio workspace include path contains the location to all of your test unit declaration (header) files.</li><br />
<li>Once you have created one or more test units, ensure the following:<br />
:* Workspace is compiled and saved<br />
:* Intercept Module is generated (Stubs for all Test Units)<br />
:* Target application re-built<br />
:* Target application downloaded & started<br />
:* STRIDE Connected to Target<br />
</li><br />
<br />
<li>If your application is running, you can start executing test units.<br />
:* You can test-execute individual test units interactively using the '''Studio interface''' view. To do this, open the user interface view corresponding to the test unit you would like to execute, then call it. The return values will indicate how many tests produced each of four (4) result types. Furthermore, the input to the entry point will allow you to select all methods for execution (the default) or individual methods via a dropdown list of enumerated values.<br />
:* Once you are confident that the test units are behaving as expected, you can generate one or more execution scripts using the '''Script Wizard'''. Sample '''[[templates]]''' for executing test unit entry points are provided in the %STRIDE_DIR%\templates\Script Wizard directory.<br />
:* When writing scripts to execute test units, the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection is a powerful tool for test unit execution and reporting, and for obtaining test results.</li><br />
<li>For integration with larger regression test workspaces, we recommend that developers check in their test unit code and, optionally, the template-generated scripts that can be used to execute their test units.</li><br />
</ol><br />
<br />
===Pragmas for Test Units===<br />
STRIDE supports three pragmas for capturing and qualifying test units: <br />
<br />
*'''<code>scl_test_class ( class-name )</code>''': Declares a test class as captured. Once captured, STRIDE will generate the appropriate code for executing the test methods in the class. See the [[scl_test_class|scl_test_class page]] for more information.<br />
*'''<code>scl_test_flist ( test-unit-name , test-function-name { , test-function-name } )</code>''': Declares a test unit as captured, by the specified test-unit-name. One or more functions (test methods) are associated with the test unit. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_flist|scl_test_flist page]] for more information.<br />
*'''<code>scl_test_cclass ( struct-name , init-function-name { , deinit-function-name } )</code>''': Declares a test unit as captured. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_cclass|scl_test_cclass page]] for more information.<br />
*'''<code>scl_test_setup ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a setup fixture for the test unit. If specified, the setup method will be called before the execution of each test method. See the [[scl_test_setup|scl_test_setup page]] for more information.<br />
*'''<code>scl_test_teardown ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a teardown fixture for the test unit. If specified, the teardown method will be called after the execution of each test method. See the [[scl_test_teardown|scl_test_teardown page]] for more information.<br />
<br />
== Test Unit Requirements ==<br />
<br />
Several variations on typical xUnit-style test units are supported. The additional supported features include: <br />
<br />
*Test status can be set using STRIDE Runtime APIs ''or'' by specifying simple return types for test methods. <br />
*Simple return types: 0 = PASS; &lt;&gt; 0 = FAIL <br />
*void return type with no explict status setting is assumed PASS <br />
*Test writers can create additional child suites and tests at runtime by using Runtime APIs. <br />
*We do not rely on exceptions for reporting of status.<br />
<br />
The STRIDE test class framework has the following requirements of each test class: <br />
<br />
*The test class must have a suitable default (no-argument) constructor. <br />
*The test class must have one or more public methods suitable as test methods. Allowable test methods always take no arguments (void) and return either void or simple integer types (int, short, long, char or bool). At this time, we do not allow typedef types or macros for the return values specification. <br />
*the scl_test_class pragma must be applied to the class.<br />
<br />
<br />
=== Simple example using return values for status ===<br />
==== Using a Test Class ====<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int tc_Int_ExpectPass(void) {return 0;}<br />
int tc_Int_ExpectFail(void) {return -1;}<br />
bool tc_Bool_ExpectPass(void) {return true;}<br />
bool tc_Bool_ExpectFail(void) {return false;}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(Simple)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int tf_Int_ExpectPass(void) {return 0;}<br />
int tf_Int_ExpectFail(void) {return -1;}<br />
bool tf_Bool_ExpectPass(void) {return true;}<br />
bool tf_Bool_ExpectFail(void) {return false;}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("Simple", tf_Int_ExpectPass, tf_Int_ExpectFail, tf_Bool_ExpectPass, tf_Bool_ExpectFail)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using runtime test service APIs ===<br />
==== Using a Test Class ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class RuntimeServices_basic {<br />
public: <br />
void tc_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(RuntimeServices_basic)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
void tf_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tf_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tf_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("RuntimeServices_basic", tf_ExpectPass, tf_ExpectFail, tf_ExpectInProgress)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using srTest base class ===<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class MyTest : public stride::srTest {<br />
public:<br />
void tc_ExpectPass(void) <br />
{<br />
testCase.AddComment("this test should pass");<br />
testCase.SetStatus(srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
testCase.AddComment("this test should fail");<br />
testCase.SetStatus(srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
testCase.AddComment("this test should be in progress");<br />
}<br />
int tc_ChangeMyName(void) <br />
{<br />
testCase.AddComment("this test should have name = MyChangedName");<br />
testCase.SetName("MyChangedName");<br />
return 0;<br />
}<br />
int tc_ChangeMyDescription(void) <br />
{<br />
testCase.AddComment("this test should have a description set");<br />
testCase.SetDescription("this is my new description");<br />
return 0;<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(MyTest)<br />
#endif<br />
</source><br />
<br />
== Runtime Test Services ==<br />
<br />
The Runtime Test Services (declared in srTest.h) are a set of APIs in the STRIDE Runtime that facilitate the writing of target based test code. These APIs make up an optional portion of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. These APIs also allow target test code to create additional test suites and test cases dynamically at runtime. <br />
<br />
There are 2 alternate ways of accessing these APIs: through C-based functions, or through a C++ base class from which you may derive your C++ test class. These are discussed below in C Test Functions, and C++ Test Classes sections below.<br />
<br />
=== C Test Functions ===<br />
<br />
The following C APIs are provided: <br />
<br />
*'''[[#srTestSuiteAddSuite|srTestSuiteAddSuite]]''': creates an additional sub-suite at runtime. <br />
*'''[[#srTestSuiteSetName|srTestSuiteSetName]]''': sets the name of the specified suite. <br />
*'''[[#srTestSuiteSetDescription|srTestSuiteSetDescription]]''': sets the description of the specified suite. <br />
*'''[[#srTestSuiteAddTest|srTestSuiteAddTest]]''': creates an additional test case at runtime. <br />
*'''[[#srTestCaseSetName|srTestCaseSetName]]''': sets the name of the specified test case. <br />
*'''[[#srTestCaseSetDescription|srTestCaseSetDescription]]''': sets the description of the specified test case. <br />
*'''[[#srTestCaseAddComment|srTestCaseAddComment]]''': adds a comment to the specified test case. <br />
*'''[[#srTestCaseSetStatus|srTestCaseSetStatus]]''': explicitly sets the status for the specified test case.<br />
*'''[[#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]]''': creates an annotation at runtime. <br />
*'''[[#srTestAnnotationAddComment|srTestAnnotationAddComment]]''': adds a comment to the specified annotation.<br />
<br />
<br />
==== srTestSuiteAddSuite ====<br />
The srTestSuiteAddSuite() routine is used to add a new test suite to the specified test suite.<br />
<source lang=c><br />
srTestSuiteHandle_t srTestSuiteAddSuite(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test suite is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test suite. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
|srTestSuiteHandle_t <br />
| Handle of the newly created test suite. srTEST_SUITE_INVALID indicates failure to create test suite.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addSuite(void)<br />
{<br />
srTestSuiteHandle_t subSuite =<br />
srTestSuiteAddSuite(srTEST_SUITE_DEFAULT, "tf Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addSuite)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetName ====<br />
The srTestSuiteSetName() routine is used to set the name of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetName(srTestSuiteHandle_t tTestSuite, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_setName(void)<br />
{<br />
srTestSuiteSetName(srTEST_SUITE_DEFAULT, "Setting name for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetDescription ====<br />
The srTestSuiteSetDescription() routine is used to set the description of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetDescription(srTestSuiteHandle_t tTestSuite, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include "srtest.h"<br />
void tfsuite_setDescription(void)<br />
{<br />
srTestSuiteSetDescription(srTEST_SUITE_DEFAULT,<br />
"Setting description for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddTest ====<br />
The srTestSuiteAddTest() routine is used to add a new test case to the specified test suite.<br />
<source lang=c><br />
srTestCaseHandle_t srTestSuiteAddTest(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test case is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test case. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCaseHandle_t <br />
| Handle of the newly created test case. srTEST_CASE_INVALID indicates failure to create test case.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
void tfsuite_addTest(void)<br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "dynamic test case %d", count);<br />
srTestCaseHandle_t test = srTestSuiteAddTest(srTEST_SUITE_DEFAULT, szName);<br />
srTEST_ADD_COMMENT_WITH_LOCATION(test, "this is a dynamic test case");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addTest)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetName ====<br />
The srTestCaseSetName() routine is used to set set the name of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetName(srTestCaseHandle_t tTestCase, const srCHAR *szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setName(void)<br />
{<br />
srTestCaseSetName(srTEST_CASE_DEFAULT, "Setting name for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetDescription ====<br />
The srTestCaseSetDescription() routine is used to set the description of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetDescription(srTestCaseHandle_t tTestCase, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setDescription(void)<br />
{<br />
srTestCaseSetDescription(srTEST_CASE_DEFAULT,<br />
"Setting description for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseAddComment ====<br />
The srTestCaseAddComment() routine is used to add a comment (aka a log) to be reported with the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseAddComment(srTestCaseHandle_t tTestCase, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_addComment(void)<br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_addComment)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatus ====<br />
The srTestCaseSetStatus() routine is used to set the result of test case.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input <br />
| The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatus(void)<br />
{<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatus)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatusEx ====<br />
The srTestCaseSetStatusEx() routine is used to set the result of test case and allow specification of an extendedFailureCode.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration, srLONG lExtendedFailureCode)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test. dwDuration Input The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|-<br />
| lExtendedFailureCode <br />
| Input <br />
| The Stride framework uses the extendedFailureCode to capture the numeric results of test method when the test method fails via a numeric (non-void, nonbool) return type.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatusEx(void)<br />
{<br />
srTestCaseSetStatusEx(srTEST_CASE_DEFAULT, srTEST_FAIL, 0, -5);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatusEx)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddAnnotation ====<br />
The srTestSuiteAddAnnotation() routine is used to add a new annotation to the specified test suite.<br />
<source lang=c><br />
srTestAnnotationHandle_t srTestSuiteAddAnnotation(rTestSuiteHandle_t tParent, srTestAnnotationLevel_e eLevel, const srCHAR * szName, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new annotation is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| eLevel<br />
| Input <br />
| Annotation level. Cannot be empty.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of annotation. If null, the default host naming scheme will be used.<br />
|-<br />
| szDescr<br />
| Input <br />
| Pointer to a null-terminated string representing the description of annotation. If null, description will be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotationHandle_t <br />
| HHandle of the newly created annotation. srTEST_ANNOTATION_INVALID indicates failure to create annotation.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addAnnotation(void) <br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "annotation %d", count);<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
szName,<br />
"description of annotation");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addAnnotation)<br />
#endif<br />
</source><br />
<br />
==== srTestAnnotationAddComment ====<br />
The srTestAnnotationAddComment() routine is used to add a comment (aka a log) to be reported with the specified annotation.<br />
<source lang=c><br />
srWORD srTestAnnotationAddComment(srTestAnnotationHandle_t tTestAnnotation, const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestAnnotation<br />
| Input<br />
| Handle to an annotation created using srTestSuiteAddAnnotation.<br />
|-<br />
| szLabel<br />
| Input <br />
| Pointer to a null-terminated string for the label. If null, the default label will be applied.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuiteAnnotation_addComment(void) <br />
{<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
“annot”,<br />
“annot description”);<br />
srTestAnnotationAddComment(annot,<br />
srNULL,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuiteAnnotation_addComment)<br />
#endif<br />
</source><br />
<br />
=== C++ Test Classes ===<br />
The Runtime Test Services C APIs work equally well from C test functions and C++ test classes. If, however, you are using C++ it might be more convinient for you to derive your C++ test classes from the Runtime Test Services C++ base class, ''srTest''. That way you will have access to a set of simpler to use C++ classes. <br />
<br />
The following C++ classes are provided: <br />
* '''[[#class srTest|class srTest]]''' - base test class<br />
* '''[[#class srTestSuite|class srTestSuite]]''' - represents a test suite<br />
* '''[[#class srTestCase|class srTestCase]]''' - represents a test case<br />
* '''[[#class srTestAnnotation|class srTestAnnotation]]''' - represents a test annotation<br />
<br />
==== class srTest ====<br />
The srTest class provides two Member Objects:<br />
*''testSuite'' of class srTestSuite <br />
*''testCase''of class srTestCase<br />
<br />
==== class srTestSuite ====<br />
The srTest class provides the folowing methods:<br />
<br />
===== method AddSuite =====<br />
The AddSuite method is used to add a new test suite.<br />
<source lang=cpp><br />
srTestSuite AddSuite(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
|szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test suite. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestSuite <br />
| Newly created test suite class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
stride::srTestSuite suite = testSuite.AddSuite("tc Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test suite.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetName(void);<br />
};<br />
<br />
void srtest_class::suiteSetName(void)<br />
{<br />
testSuite.SetName("Setting name for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test suite.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|- <br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetDescription(void);<br />
};<br />
<br />
void srtest_class::suiteSetDescription(void)<br />
{<br />
testSuite.SetDescription("Setting description for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddTest =====<br />
The AddTest method is used to add a new test case to test suite.<br />
<source lang=cpp><br />
srTestCase AddTest(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test case. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCase <br />
| Newly created test case class.<br />
|}<br />
<br><br />
'''Example'''<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
const std::string prefix("dynamic test case ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strm;<br />
strm << prefix << count;<br />
stride::srTestCase tc = testSuite.AddTest(strm.str().c_str());<br />
tc.AddComment("this is a dynamic test case");<br />
tc.SetStatus(srTEST_PASS);<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddAnnotation =====<br />
The AddAnnotation method is used to add a new annotation to test suite.<br />
<source lang=cpp><br />
srTestAnnoation AddAnnotation(srTestAnnotationLevel_e eLevel, const srCHAR * szName = srNULL, const srCHAR * szDescr = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eLevel<br />
| Input<br />
| Annotation level. Cannot be empty.<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of annotation. If empty, the default host naming scheme will be used.<br />
|- <br />
| szDescr<br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the description of annotation. If empty, the description will be blank.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotation<br />
| Newly created annotation class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddAnnotation(void);<br />
};<br />
<br />
void srtest_class::suiteAddAnnotation(void) <br />
{<br />
const std::string prefixName("annotation ");<br />
const std::string prefixDescr("description of annotation ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strmName;<br />
std::stringstream strmDescr;<br />
strmName << prefixName << count;<br />
strmDescr << prefixDescr << count;<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
strmName.str().c_str(),<br />
strmDescr.str().c_str());<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestCase ====<br />
The srTestCase class provides the following methods:<br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test case.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetName(void);<br />
};<br />
<br />
void srtest_class::caseSetName(void)<br />
{<br />
testCase.SetName("Setting name for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test case.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetDescription(void);<br />
};<br />
<br />
void srtest_class::caseSetDescription(void)<br />
{<br />
testCase.SetDescription("Setting description for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to test case.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseAddComment(void);<br />
};<br />
<br />
void srtest_class::caseAddComment(void)<br />
{<br />
testCase.AddComment("this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetStatus =====<br />
The SetStatus method is used to set the result of the default test case.<br />
<source lang=cpp><br />
srWORD SetStatus(srTestStatus_e eStatus, srDWORD dwDuration = 0)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input (Optional)<br />
| The duration of the test in clock ticks. The default is 0.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetStatus(void);<br />
};<br />
<br />
void srtest_class::caseSetStatus(void)<br />
{<br />
testCase.SetStatus(srTEST_INPROGRESS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestAnnotation ====<br />
The srTestAnnotation class provides the following methods:<br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to an annotation created under a test suite.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szLabel<br />
| Input <br />
| Pointer to null-terminated string for the label. If null, the default label will be applied.<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAnnotationAddComment(void);<br />
};<br />
<br />
void srtest_class::suiteAnnotationAddComment(void)<br />
{<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
“annot”,<br />
“annot description”);<br />
ta.AddComment("this comment on annotation should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
Refer to the [[Media:s2sSCLReferenceGuide.pdf|SCL Reference Guide]] or the [[Media:s2sRuntime.pdf|Runtime Developer's Guide]] for detailed information about any of these APIs.<br />
<br />
== ASSERT/EXPECT Macros ==<br />
<br />
The STRIDE Test Unit implementation also provides a set of Test Macros available for use within test methods. The macros are optional - you are not required to use them in your test units. They provide shortcuts for testing assertions and automatic report annotation in the case of failures. <br />
<br />
The macros can currently only be used in C++ test unit code. <br />
<br />
=== General guidelines for all macros ===<br />
<br />
srEXPECT_xx macros will set the current test case to fail (if it hasn’t already been set) and produce an annotation in the report if the expectation fails. If the expectation succeeds, there is no action. <br />
<br />
srASSERT_xx macros will set the current test case to fail (if it hasn’t already been set) and insert an annotation into the report if the assertion fails. In addition, a return from the current function will occur. srASSERT_xx macros can only be used in test functions which return void. If the assertion succeeds there is no action. <br />
<br />
The report annotation produced by a failed macro always includes the source file and line along with details about the condition that failed and the failing values. <br />
<br />
<nowiki>All the macros support the adding to the report annotations using the << operator. For example:</nowiki><br />
<br />
srEXPECT_TRUE( a != <nowiki>b) << “My custom message”; </nowiki><br />
<br />
<nowiki>As delivered, the macros will support stream operator annotations using all the numeric types, char* and s2String. The user may create custom types to be used a report annotation by providing an implementation of the << operator for their custom type. The details are explained in a section below. </nowiki><br />
<br />
=== Boolean Macros ===<br />
The boolean macros take a single condition expression, ''cond'', that evaluates to an integral type or bool. The condition will be evaluated once. if ''cond'' evaluates to non-zero the assertion or expectation fails. When a failure occurs the report will be annotated. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE(''cond'');<br />
| srASSERT_TRUE(''cond'');<br />
| ''cond'' is true<br />
<br />
|-<br />
| srEXPECT_FALSE(''cond'');<br />
| srASSERT_FALSE(''cond'');<br />
| ''cond'' is false<br />
<br />
|}<br />
<br />
=== Comparison Macros ===<br />
<br />
Comparison macros take two operands and compare them using the indicated operator. The comparison macros will work for primitive types as well as objects that have the corresponding comparison operator implemented. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ(''val1'', ''val2'');<br />
| srASSERT_EQ(''val1'', ''val2'');<br />
| ''val1'' == ''val2''<br />
<br />
|-<br />
| srEXPECT_NE(''val1'', ''val2'');<br />
| srASSERT_NE(''val1'', ''val2'');<br />
| ''val1'' != ''val2''<br />
<br />
|-<br />
| srEXPECT_LT(''val1'', ''val2'');<br />
| srASSERT_LT(''val1'', ''val2'');<br />
| ''val1''<nowiki> < </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_LE(''val1'', ''val2'');<br />
| srASSERT_LE(''val1'', ''val2'');<br />
| ''val1''<nowiki> <= </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_GT(''val1'', ''val2'');<br />
| srASSERT_GT(''val1'', ''val2'');<br />
| ''val1'' > ''val2''<br />
<br />
|-<br />
| srEXPECT_GE(''val1'', ''val2'');<br />
| srASSERT_GE(''val1'', ''val2'');<br />
| ''val1'' >= ''val2''<br />
<br />
|}<br />
<br />
=== C String Comparison Macros ===<br />
<br />
C String Comparison Macros are intended only for use with C-style zero terminated strings. The strings can be char or wchar_t based. In particular, these macros should not be used for object of one or other string class, since such classes have overloaded comparison operators. The standard comparison macros should be used instead. <br />
<br />
* The length of a string displayed in the report annotation message is controllable via the following macro: srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY (found in srtestmacros.h). If a string value is truncated because of the length limit, the text "...(trunc)" will always appear next to it. <br />
* An empty string will appear in error message output as “”. A null string will appear as NULL with no surrounding quotes. Otherwise all output strings are quoted. <br />
* The type of str1 and str2 must be compatible with const char* or const wchar_t*. <br />
<br />
<br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ(''str1'', ''str2'');<br />
| srASSERT_STREQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content<br />
<br />
|-<br />
| srEXPECT_STRNE(''str1'', ''str2'');<br />
| srASSERT_STRNE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ(''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content, ignoring case.<br />
<br />
|-<br />
| srEXPECT_STRCASENE(''str1'', ''str2'');<br />
| srASSERT_STRCASENE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content, ignoring case.<br />
<br />
|}<br />
<br />
=== Exception Macros ===<br />
Exception macros are used to ensure that expected exceptions are thrown. They require exception support from the target compiler. If the target compiler does not have exception support the macros cannot be used and must be disabled. The support can be disabled via the macro srCFG_TEST_MACROS_EXCEPTIONS_ON found in srtestmacros.h. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW(statement, ex_type);<br />
| srASSERT_THROW(statement, ex_type);<br />
| ''statement'' throws an exception of type ''ex_type''<br />
<br />
|-<br />
| srEXPECT_THROW_ANY(''statement'');<br />
| srASSERT_THROW_ANY(''statement'');<br />
| ''statement'' throws an exception (type not important)<br />
<br />
|-<br />
| srEXPECT_NO_THROW(''statement'');<br />
| srASSERT_NO_THROW(''statement'');<br />
| ''statement'' does not throw an exception<br />
<br />
|}<br />
<br />
=== Predicate Macros ===<br />
Predicate macros allow user control over the pass/fail decision making in a macro. A predicate is a function returning bool that is implemented by the user but passed to the macro. Other arguments for the predicate are also passed to the macro. The macros allow for predicate functions with up to four parameters. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1(''pred'', ''val1'')<br />
| srASSERT_PRED1(''pred'', ''val1'')<br />
| ''pred''(''val1'') returns true<br />
<br />
|-<br />
| srEXPECT_PRED2(''pred'', ''vall'', ''val2'')<br />
| srASSERT_PRED2(''pred'', ''vall'', ''val2'')<br />
| ''pred''(''val1'', ''val2'') returns true<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
| <br />
<br />
|}<br />
All predicate macros require a predicate function function which returns bool. The predicate macros allow functions with one to 4 parameters. Following are the report annotations resulting from expectation or assertion failures.<br />
<br />
=== Floating Point Macros ===<br />
<br />
Floating point macros are for comparing equivalence (or near equivalence) of floating point numbers. These macros are necessary since because equivalence comparisons for floating point numbers will often fail due to round-off errors. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Floating Point Macros'''<br />
<br />
|-<br />
| srEXPECT_NEAR(val1, val2, epsilon);<br />
| srASSERT_NEAR(val1, val2, epsilon);<br />
| The absolute value of the difference between val1 and val2 is epsilon.<br />
|}<br />
<br />
=== Dynamic Test Case Macros ===<br />
The macros presented so far are not capable of dealing with dynamic test cases. In order to handle dynamic test cases, each of the macros requires another parameter which is the test case to report against. Other than this, these macros provide exactly equivalent functionality to the non-dynamic peer. The dynamic macros are listed below. All require a test case, value of type srTestCaseHandle_t from srtest.h, to be passed as the first parameter).<br />
<br />
{| class="prettytable"<br />
| '''''Nonfatal assertion'''''<br />
| '''''Fatal Assertion'''''<br />
<br />
|-<br />
| colspan="2" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE_DYN(tc, ''cond'');<br />
| srASSERT_TRUE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| srEXPECT_FALSE_DYN(tc, ''cond'');<br />
| srASSERT_FALSE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| colspan="2" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_EQ_DYN(tc, ''expect'', ''val'');<br />
<br />
|-<br />
| srEXPECT_NE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_NE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| colspan="2" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| colspan="2" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW_DYN(statement, ex_type);<br />
| srASSERT_THROW_DYN(tc, statement, ex_type);<br />
<br />
|-<br />
| srEXPECT_THROW_ANY_DYN(tc, ''statement'');<br />
| srASSERT_THROW_ANY_DYN(tc, ''statement'');<br />
<br />
|-<br />
| srEXPECT_NO_THROW_DYN(tc, ''statement'');<br />
| srASSERT_NO_THROW_DYN(tc, ''statement'');<br />
<br />
|-<br />
| colspan="2" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
| srASSERT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
<br />
|-<br />
| srEXPECT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
| srASSERT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
<br />
|-<br />
| colspan="2" | '''Floating Point'''<br />
<br />
|-<br />
| srEXPECT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
| srASSERT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
<br />
|}<br />
<br />
=== Overloading The << operator for report annotation ===<br />
<nowiki>The user of the asserting macros package may overload the << operator in order to annotate reports using a custom class. An example is below. </nowiki><br />
<br />
<nowiki>The following will compile and execute successfully given that the << operator is overloaded as shown:</nowiki><br />
<br />
<pre><br />
MyCustomClass custom(34); <br />
<br />
srEXPECT_FALSE(true) << custom;<br />
<br />
// MyCustomClass implementation<br />
class MyCustomClass<br />
{<br />
public:<br />
MyCustomClass(int i) : m_int(i) {}<br />
<br />
private: <br />
int m_int; <br />
friend stride::Message& operator<< <br />
( stride::Message& ss, const MyCustomClass& obj);<br />
}; <br />
<br />
stride::Message& operator<<(stride::Message& ss, const MyCustomClass& obj)<br />
{<br />
<br />
// format the internals as a string and send on<br />
char buf[20]; <br />
sprintf(buf, "%d", obj.m_int); <br />
ss << buf;<br />
return ss;<br />
}<br />
</pre><br />
<br />
=== Test Macro Configuration ===<br />
<br />
The Test Macros are implemented in C++. Because target support for use of the standard libraries and exceptions varies across targets the macro implementation can be configured. <br />
<br />
==== Configuring Test Macros When Exceptions Not Available ====<br />
If the target compiler does not support exceptions (or they are disabled) the Exception Macros must be disabled. This is accomplished by setting srCFG_TEST_MACROS_EXCEPTIONS_ON to 0 in the file srtestmacros.h.<br />
<br />
==== Configuring Test Macros When C++ Standard Library is Not Available ====<br />
If the C++ standard library can be used within the target code, the test macro implementation uses std::string and std::stringstream. If the classes are not available on the target, then an alternate, custom implementation that relies only on C library support can be used. <br />
<br />
The choice is configured via srCFG_TEST_MACROS_USE_STANDARD_LIB found within srtestmacros.h<br />
<br />
==== Configuring Report Annotation for C-String Comparisons ====<br />
<br />
The C-String comparison macros are used to compare strings. When comparisons fail, the values involved in the failed comparison are normally displayed in the report. If the strings are very long, this is probably not desirable. It is possible to constrain the maximum length of the displayed strings using srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY. String values longer than this value will be truncated in report annotations. <br />
<br />
<br />
== Scripting a Test Unit ==<br />
<br />
To automate the execution and reporting of a Test Unit a script is required. Scripts can be written by hand or automatically generated using the Script Wizard and a corresponding template script. A scripting tool for executing a test unit is the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection. An [[AutoScript#ascript.TestUnits.Item|Ascript TestUnit]] object assembles all of the reporting information for the test unit and its corresponding test methods. <br />
<br />
*Require usage of the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection <br />
*Can be written by hand (refer below) <br />
*Can leverage [[Templates|Templates]] via the Script Wizard <br />
*Order of multiple test units dictated by SUID assignment<br />
<br />
<br> <br />
<br />
=== JScript example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=javascript><br />
// Ensure test unit exists<br />
if (ascript.TestUnits.Item("Simple") != null) <br />
ascript.TestUnits.Item("Simple").Run();<br />
</source><br />
<br />
=== Perl example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
my $tu = $main::ascript->TestUnits->Item("Simple");<br />
if (defined $tu) {<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
=== JScript example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=javascript><br />
var Units = ["Simple1","Simple2"];<br />
<br />
// iterate through each function<br />
for (i in Units)<br />
{<br />
var tu = ascript.TestUnits.Item(Units[i]);<br />
if ( tu&nbsp;!= null ) <br />
tu.Run();<br />
}<br />
</source><br />
<br />
=== Perl example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
# initialize an array with all selected function names<br />
my @UnitNames = ("Simple1","Simple2");<br />
foreach (@UnitNames) { <br />
my $tu = $main::ascript->TestUnits->Item($_->[1]);<br />
die "TestUnit not found: $_->[1]\n" unless (defined $tu);<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
[[Category:Test Units]]<br />
[[Category:Reference]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Studio:Desktop_Installation&diff=8955Studio:Desktop Installation2009-01-23T00:05:14Z<p>Jaimeg: /* Perl */</p>
<hr />
<div>== Getting Started ==<br />
STRIDE software, which is typically provided either via an FTP site or on a CD, contains STRIDE Studio and the STRIDE Runtime, as well as other software and utilities. <br />
<br />
To install and use STRIDE, your Windows-based PC must have the following ''minimum'' configuration:<br />
* 30 GB hard disk<br />
* Windows® XP SP2 or greater<br />
* 512 KB RAM (recommended: 1 GB )<br />
* Pentium 4 CPU 2 GHz (recommended: 3.20 GHz)<br />
* 1024 x 768 display (1280 x 1024 recommended)<br />
<br />
=== Obtaining a license and a copy of STRIDE ===<br />
STRIDE is a license-controlled product. All users running STRIDE Studio on a Windows PC must have a valid license installed.<br />
<br />
If your company is engaged in a VaS or TAGS project with S2 Technologies, current license files, as well as all STRIDE binaries, will be available on your project's Basecamp site.<br />
<br />
If you are not yet a customer of S2 and would like to obtain an evaluation license, email [mailto:sales@s2technologies.com S2 Sales] or call our offices at '''760-635-2345'''.<br />
<br />
=== Third Party Components ===<br />
==== Perl ====<br />
Many of our additional test utilities and libraries require perl support on the host. In particular, we require:<br />
* Distribution of [http://activestate.com/Products/activeperl/ ActiveState perl] '''5.8.8.822''', or a later build of 5.8.x perl. We '''DO NOT''' support perl version 5.10.x at this time due to some bugs in the script component support in perl 5.10. You can download perl distributions from [http://downloads.activestate.com/ActivePerl/Windows/ ActiveState]). These distributions include the PerlScript engine that is required for use with STRIDE.<br />
* We recommend that the following repositories are added:<br />
** http://theoryx5.uwinnipeg.ca/ppms<br />
** http://www.bribes.org/perl/ppm<br />
** http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58<br />
You can add a ppm repository using the command line interface as follows:<br />
CMD> ppm repo add http://www.bribes.org/perl/ppm<br />
(change the last argument by specifying [http://win32.perl.org/wiki/index.php?title=PPM_Repositories any other repository])<br />
<br />
'''Note:''' PPM uses HTTP to communicate with repositories -- if your HTTP connections require a proxy server, refer to [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html#ppm_and_proxies the PPM documentation] for information about setting the proxy.<br />
<br />
* The following additional perl packages, which can all be installed using the [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html Perl Package Manager] (PPM) that comes with ActiveState perl.<br />
**Win32::API<br />
**Win32::GUI<br />
**Win32::GuiTest<br />
**Win32::ToolHelp<br />
**XML::DOM<br />
**Config::IniFiles<br />
**Getopt::Long<br />
**NET::DNS<br />
**Log::Handler<br />
The simplest way to install these packages is via the command line interface to PPM, e.g<br />
CMD> ppm install win32-api<br />
(change the last argument accordingly for each required package)<br />
<br />
'''Note:''' Due to bandwidth issues at ActiveState, PPM attempts may fail intermittently. If so, please re-try. <br />
<br />
Verify all the packages have been installed via PPM<br />
CMD> ppm list<br />
<br />
We provide a perl script, ''TestInstallOfPerl.pl'', that can be used to validate the version and packages that you have installed. This script is available in ''%STRIDE_DIR%/Scripts'' folder. Run this script from a command prompt by typing <tt>perl TestInstallOfPerl.pl</tt>. On a properly configured system, it will produce results like:<br />
<br />
************************************************************<br />
Perl/System prerequisites check<br />
************************************************************<br />
OK: Perl version looks good (5.010000).<br />
OK: Package Win32::API looks good.<br />
OK: Package Win32::GUI looks good.<br />
OK: Package Win32::GuiTest looks good.<br />
OK: Package Win32::ToolHelp looks good.<br />
OK: Package XML::DOM looks good.<br />
OK: Package Config::IniFiles looks good.<br />
OK: Package Getopt::Long looks good.<br />
OK: Package NET::DNS looks good.<br />
OK: Package Log::Handler looks good.<br />
OK: Prerequisites validation successful.<br />
************************************************************<br />
<br />
'''Note:''' For the later 5.8 versions of Perl, you may see several lines of debug code above the line that verifies the NET::DNS package. This debugging code is not a sign of unsuccessful installation and can be ignored. <br />
<br />
You should address any errors that are reported before proceeding. If you prefer to install perl '''after''' installing STRIDE, you '''must''' run this script after both are installed to verify the packages and perform the necessary STRIDE component registrations.<br />
<br />
== STRIDE Installation ==<br />
STRIDE is usually installed in the '''C:\STRIDE''' directory. Installing the core components will provide everything needed to run STRIDE on the host. <br />
<br />
'''Step-by-step instructions:'''<br />
<br />
# Exit all other Windows applications prior to beginning the STRIDE installation.<br />
# If you haven't already done so, obtain a current copy of StrideSetup.exe from you project's Basecamp site.<br />
# Select and open '''StrideSetup.exe'''.<br />
# When the Install Wizard appears, click '''Next'''.<br />
# On the '''License Agreement''' screen, click '''I Agree''' if you agree with the terms of the license and to continue the installation.<br> '''Note:''' Clicking '''No''' will terminate the installation process.<br />
# Click '''Install''' to install the Core Components, which provides the full installation of STRIDE.<br />
# When the installation is complete, click '''Finish'''. <br />
<br />
Once the installation is complete, you must have your '''license''' information ready before starting STRIDE. If you have an evaluation or node-locked license, place the license file in '''C:\STRIDE\lic''' before launching STRIDE Studio. If you are using a '''floating license''', you will be prompted for the location of the license server when you first start STRIDE. After your license setup is complete, you are ready to begin Integrating STRIDE into your Target environment.<br />
<br />
''It is highly recommended to run through the '''[[Hello_Stride_Sample | Hello Stride Sample]]''' after completing the Desktop installation.''<br />
<br />
== Conducting an unattended installation ==<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently install STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\TEMP" C:\TEMP\StrideSetup.exe /S<br />
<br />
'''Note:''' The statement above assumes that '''StrideSetup.exe''' resides in C:\TEMP; you may need to change this path to match your actual StrideSetup.exe location.<br />
<br />
== Uninstalling Host ==<br />
<br />
'''Method 1 (via Control Panel)<br />
# From the '''Start''' menu, select '''Control Panel'''.<br />
# Double-click '''Add or Remove Programs'''.<br />
# Select '''Stride''', then click '''Change/Remove'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 2 (via STRIDE Program Folder)<br />
# From the '''Start''' menu, go to '''STRIDE 3.0''' Program folder.<br />
# Select '''STRIDE Uninstall'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 3 (via STRIDE Installation Folder)<br />
# Open the '''STRIDE installation folder''' (typically C:\STRIDE).<br />
# Go to '''uninstall''' folder.<br />
# Select and open '''STRIDEUninstall.exe'''.<br />
# When the Install Wizard appears, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
=== Conducting an unattended uninstallation ===<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently uninstall STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\STRIDE\uninstall" C:\STRIDE\uninstall\StrideUninstall.exe "/S _?=C:\STRIDE"<br />
<br />
<br />
[[Category:Installation]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Studio:Desktop_Installation&diff=8954Studio:Desktop Installation2009-01-22T23:59:56Z<p>Jaimeg: /* Perl */</p>
<hr />
<div>== Getting Started ==<br />
STRIDE software, which is typically provided either via an FTP site or on a CD, contains STRIDE Studio and the STRIDE Runtime, as well as other software and utilities. <br />
<br />
To install and use STRIDE, your Windows-based PC must have the following ''minimum'' configuration:<br />
* 30 GB hard disk<br />
* Windows® XP SP2 or greater<br />
* 512 KB RAM (recommended: 1 GB )<br />
* Pentium 4 CPU 2 GHz (recommended: 3.20 GHz)<br />
* 1024 x 768 display (1280 x 1024 recommended)<br />
<br />
=== Obtaining a license and a copy of STRIDE ===<br />
STRIDE is a license-controlled product. All users running STRIDE Studio on a Windows PC must have a valid license installed.<br />
<br />
If your company is engaged in a VaS or TAGS project with S2 Technologies, current license files, as well as all STRIDE binaries, will be available on your project's Basecamp site.<br />
<br />
If you are not yet a customer of S2 and would like to obtain an evaluation license, email [mailto:sales@s2technologies.com S2 Sales] or call our offices at '''760-635-2345'''.<br />
<br />
=== Third Party Components ===<br />
==== Perl ====<br />
Many of our additional test utilities and libraries require perl support on the host. In particular, we require:<br />
* Distribution of [http://activestate.com/Products/activeperl/ ActiveState perl] '''5.8.8.822''', or a later build of 5.8.x perl. We '''DO NOT''' support perl version 5.10.x at this time due to some bugs in the script component support in perl 5.10. You can download perl distributions from [http://downloads.activestate.com/ActivePerl/Windows/ ActiveState]). These distributions include the PerlScript engine that is required for use with STRIDE.<br />
* We recommend that the following repositories are added:<br />
** http://theoryx5.uwinnipeg.ca/ppms<br />
** http://www.bribes.org/perl/ppm<br />
** http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58<br />
You can add a ppm repository on the command line as follows:<br />
CMD> ppm repo add http://www.bribes.org/perl/ppm<br />
(change the last argument by specifying [http://win32.perl.org/wiki/index.php?title=PPM_Repositories any other repository])<br />
<br />
'''Note:''' PPM uses HTTP to communicate with repositories -- if your HTTP connections require a proxy server, refer to [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html#ppm_and_proxies the PPM documentation] for information about setting the proxy.<br />
<br />
* The following additional perl packages, which can all be installed using the [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html Perl Package Manager] (PPM) that comes with ActiveState perl.<br />
**Win32::API<br />
**Win32::GUI<br />
**Win32::GuiTest<br />
**Win32::ToolHelp<br />
**XML::DOM<br />
**Config::IniFiles<br />
**Getopt::Long<br />
**NET::DNS<br />
**Log::Handler<br />
The simplest way to install these packages is via the command line interface to PPM, e.g<br />
CMD> ppm install win32-api<br />
(change the last argument accordingly for each required package)<br />
<br />
'''Note:''' Due to bandwidth issues at ActiveState, PPM attempts may fail intermittently. If so, please re-try. <br />
<br />
Verify all the packages have been installed via PPM<br />
CMD> ppm list<br />
<br />
We provide a perl script, ''TestInstallOfPerl.pl'', that can be used to validate the version and packages that you have installed. This script is available in ''%STRIDE_DIR%/Scripts'' folder. Run this script from a command prompt by typing <tt>perl TestInstallOfPerl.pl</tt>. On a properly configured system, it will produce results like:<br />
<br />
************************************************************<br />
Perl/System prerequisites check<br />
************************************************************<br />
OK: Perl version looks good (5.010000).<br />
OK: Package Win32::API looks good.<br />
OK: Package Win32::GUI looks good.<br />
OK: Package Win32::GuiTest looks good.<br />
OK: Package Win32::ToolHelp looks good.<br />
OK: Package XML::DOM looks good.<br />
OK: Package Config::IniFiles looks good.<br />
OK: Package Getopt::Long looks good.<br />
OK: Package NET::DNS looks good.<br />
OK: Package Log::Handler looks good.<br />
OK: Prerequisites validation successful.<br />
************************************************************<br />
<br />
'''Note:''' For the later 5.8 versions of Perl, you may see several lines of debug code above the line that verifies the NET::DNS package. This debugging code is not a sign of unsuccessful installation and can be ignored. <br />
<br />
You should address any errors that are reported before proceeding. If you prefer to install perl '''after''' installing STRIDE, you '''must''' run this script after both are installed to verify the packages and perform the necessary STRIDE component registrations.<br />
<br />
== STRIDE Installation ==<br />
STRIDE is usually installed in the '''C:\STRIDE''' directory. Installing the core components will provide everything needed to run STRIDE on the host. <br />
<br />
'''Step-by-step instructions:'''<br />
<br />
# Exit all other Windows applications prior to beginning the STRIDE installation.<br />
# If you haven't already done so, obtain a current copy of StrideSetup.exe from you project's Basecamp site.<br />
# Select and open '''StrideSetup.exe'''.<br />
# When the Install Wizard appears, click '''Next'''.<br />
# On the '''License Agreement''' screen, click '''I Agree''' if you agree with the terms of the license and to continue the installation.<br> '''Note:''' Clicking '''No''' will terminate the installation process.<br />
# Click '''Install''' to install the Core Components, which provides the full installation of STRIDE.<br />
# When the installation is complete, click '''Finish'''. <br />
<br />
Once the installation is complete, you must have your '''license''' information ready before starting STRIDE. If you have an evaluation or node-locked license, place the license file in '''C:\STRIDE\lic''' before launching STRIDE Studio. If you are using a '''floating license''', you will be prompted for the location of the license server when you first start STRIDE. After your license setup is complete, you are ready to begin Integrating STRIDE into your Target environment.<br />
<br />
''It is highly recommended to run through the '''[[Hello_Stride_Sample | Hello Stride Sample]]''' after completing the Desktop installation.''<br />
<br />
== Conducting an unattended installation ==<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently install STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\TEMP" C:\TEMP\StrideSetup.exe /S<br />
<br />
'''Note:''' The statement above assumes that '''StrideSetup.exe''' resides in C:\TEMP; you may need to change this path to match your actual StrideSetup.exe location.<br />
<br />
== Uninstalling Host ==<br />
<br />
'''Method 1 (via Control Panel)<br />
# From the '''Start''' menu, select '''Control Panel'''.<br />
# Double-click '''Add or Remove Programs'''.<br />
# Select '''Stride''', then click '''Change/Remove'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 2 (via STRIDE Program Folder)<br />
# From the '''Start''' menu, go to '''STRIDE 3.0''' Program folder.<br />
# Select '''STRIDE Uninstall'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 3 (via STRIDE Installation Folder)<br />
# Open the '''STRIDE installation folder''' (typically C:\STRIDE).<br />
# Go to '''uninstall''' folder.<br />
# Select and open '''STRIDEUninstall.exe'''.<br />
# When the Install Wizard appears, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
=== Conducting an unattended uninstallation ===<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently uninstall STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\STRIDE\uninstall" C:\STRIDE\uninstall\StrideUninstall.exe "/S _?=C:\STRIDE"<br />
<br />
<br />
[[Category:Installation]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Studio:Desktop_Installation&diff=8953Studio:Desktop Installation2009-01-22T23:40:21Z<p>Jaimeg: /* Perl */</p>
<hr />
<div>== Getting Started ==<br />
STRIDE software, which is typically provided either via an FTP site or on a CD, contains STRIDE Studio and the STRIDE Runtime, as well as other software and utilities. <br />
<br />
To install and use STRIDE, your Windows-based PC must have the following ''minimum'' configuration:<br />
* 30 GB hard disk<br />
* Windows® XP SP2 or greater<br />
* 512 KB RAM (recommended: 1 GB )<br />
* Pentium 4 CPU 2 GHz (recommended: 3.20 GHz)<br />
* 1024 x 768 display (1280 x 1024 recommended)<br />
<br />
=== Obtaining a license and a copy of STRIDE ===<br />
STRIDE is a license-controlled product. All users running STRIDE Studio on a Windows PC must have a valid license installed.<br />
<br />
If your company is engaged in a VaS or TAGS project with S2 Technologies, current license files, as well as all STRIDE binaries, will be available on your project's Basecamp site.<br />
<br />
If you are not yet a customer of S2 and would like to obtain an evaluation license, email [mailto:sales@s2technologies.com S2 Sales] or call our offices at '''760-635-2345'''.<br />
<br />
=== Third Party Components ===<br />
==== Perl ====<br />
Many of our additional test utilities and libraries require perl support on the host. In particular, we require:<br />
* Distribution of [http://activestate.com/Products/activeperl/ ActiveState perl] '''5.8.8.822''', or a later build of 5.8.x perl. We '''DO NOT''' support perl version 5.10.x at this time due to some bugs in the script component support in perl 5.10. You can download perl distributions from [http://downloads.activestate.com/ActivePerl/Windows/ ActiveState]). These distributions include the PerlScript engine that is required for use with STRIDE.<br />
* The following additional perl packages, which can all be installed using the [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html Perl Package Manager] (PPM) that comes with ActiveState perl.<br />
**Win32::API<br />
**Win32::GUI<br />
**Win32::GuiTest<br />
**Win32::ToolHelp<br />
**XML::DOM<br />
**Config::IniFiles<br />
**Getopt::Long<br />
**NET::DNS<br />
**Log::Handler<br />
The simplest way to install these packages is via the command line interface to PPM, e.g<br />
CMD> ppm install win32-api<br />
(change the last argument accordingly for each required package)<br />
<br />
'''Note:''' Due to bandwidth issues at ActiveState, PPM attempts may fail intermittently. If so, please re-try. You may also try adding a ppm repository:<br />
CMD> ppm repo add http://www.bribes.org/perl/ppm<br />
(change the last argument by specifying [http://win32.perl.org/wiki/index.php?title=PPM_Repositories any other repository])<br />
<br />
'''Note:''' PPM uses HTTP to communicate with repositories -- if your HTTP connections require a proxy server, refer to [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html#ppm_and_proxies the PPM documentation] for information about setting the proxy.<br />
<br />
Verify all the packages have been installed via PPM<br />
CMD> ppm list<br />
<br />
We provide a perl script, ''TestInstallOfPerl.pl'', that can be used to validate the version and packages that you have installed. This script is available in ''%STRIDE_DIR%/Scripts'' folder. Run this script from a command prompt by typing <tt>perl TestInstallOfPerl.pl</tt>. On a properly configured system, it will produce results like:<br />
<br />
************************************************************<br />
Perl/System prerequisites check<br />
************************************************************<br />
OK: Perl version looks good (5.010000).<br />
OK: Package Win32::API looks good.<br />
OK: Package Win32::GUI looks good.<br />
OK: Package Win32::GuiTest looks good.<br />
OK: Package Win32::ToolHelp looks good.<br />
OK: Package XML::DOM looks good.<br />
OK: Package Config::IniFiles looks good.<br />
OK: Package Getopt::Long looks good.<br />
OK: Package NET::DNS looks good.<br />
OK: Package Log::Handler looks good.<br />
OK: Prerequisites validation successful.<br />
************************************************************<br />
<br />
'''Note:''' For the later 5.8 versions of Perl, you may see several lines of debug code above the line that verifies the NET::DNS package. This debugging code is not a sign of unsuccessful installation and can be ignored. <br />
<br />
You should address any errors that are reported before proceeding. If you prefer to install perl '''after''' installing STRIDE, you '''must''' run this script after both are installed to verify the packages and perform the necessary STRIDE component registrations.<br />
<br />
== STRIDE Installation ==<br />
STRIDE is usually installed in the '''C:\STRIDE''' directory. Installing the core components will provide everything needed to run STRIDE on the host. <br />
<br />
'''Step-by-step instructions:'''<br />
<br />
# Exit all other Windows applications prior to beginning the STRIDE installation.<br />
# If you haven't already done so, obtain a current copy of StrideSetup.exe from you project's Basecamp site.<br />
# Select and open '''StrideSetup.exe'''.<br />
# When the Install Wizard appears, click '''Next'''.<br />
# On the '''License Agreement''' screen, click '''I Agree''' if you agree with the terms of the license and to continue the installation.<br> '''Note:''' Clicking '''No''' will terminate the installation process.<br />
# Click '''Install''' to install the Core Components, which provides the full installation of STRIDE.<br />
# When the installation is complete, click '''Finish'''. <br />
<br />
Once the installation is complete, you must have your '''license''' information ready before starting STRIDE. If you have an evaluation or node-locked license, place the license file in '''C:\STRIDE\lic''' before launching STRIDE Studio. If you are using a '''floating license''', you will be prompted for the location of the license server when you first start STRIDE. After your license setup is complete, you are ready to begin Integrating STRIDE into your Target environment.<br />
<br />
''It is highly recommended to run through the '''[[Hello_Stride_Sample | Hello Stride Sample]]''' after completing the Desktop installation.''<br />
<br />
== Conducting an unattended installation ==<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently install STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\TEMP" C:\TEMP\StrideSetup.exe /S<br />
<br />
'''Note:''' The statement above assumes that '''StrideSetup.exe''' resides in C:\TEMP; you may need to change this path to match your actual StrideSetup.exe location.<br />
<br />
== Uninstalling Host ==<br />
<br />
'''Method 1 (via Control Panel)<br />
# From the '''Start''' menu, select '''Control Panel'''.<br />
# Double-click '''Add or Remove Programs'''.<br />
# Select '''Stride''', then click '''Change/Remove'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 2 (via STRIDE Program Folder)<br />
# From the '''Start''' menu, go to '''STRIDE 3.0''' Program folder.<br />
# Select '''STRIDE Uninstall'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 3 (via STRIDE Installation Folder)<br />
# Open the '''STRIDE installation folder''' (typically C:\STRIDE).<br />
# Go to '''uninstall''' folder.<br />
# Select and open '''STRIDEUninstall.exe'''.<br />
# When the Install Wizard appears, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
=== Conducting an unattended uninstallation ===<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently uninstall STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\STRIDE\uninstall" C:\STRIDE\uninstall\StrideUninstall.exe "/S _?=C:\STRIDE"<br />
<br />
<br />
[[Category:Installation]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Studio:Desktop_Installation&diff=8952Studio:Desktop Installation2009-01-22T23:18:00Z<p>Jaimeg: /* Perl */</p>
<hr />
<div>== Getting Started ==<br />
STRIDE software, which is typically provided either via an FTP site or on a CD, contains STRIDE Studio and the STRIDE Runtime, as well as other software and utilities. <br />
<br />
To install and use STRIDE, your Windows-based PC must have the following ''minimum'' configuration:<br />
* 30 GB hard disk<br />
* Windows® XP SP2 or greater<br />
* 512 KB RAM (recommended: 1 GB )<br />
* Pentium 4 CPU 2 GHz (recommended: 3.20 GHz)<br />
* 1024 x 768 display (1280 x 1024 recommended)<br />
<br />
=== Obtaining a license and a copy of STRIDE ===<br />
STRIDE is a license-controlled product. All users running STRIDE Studio on a Windows PC must have a valid license installed.<br />
<br />
If your company is engaged in a VaS or TAGS project with S2 Technologies, current license files, as well as all STRIDE binaries, will be available on your project's Basecamp site.<br />
<br />
If you are not yet a customer of S2 and would like to obtain an evaluation license, email [mailto:sales@s2technologies.com S2 Sales] or call our offices at '''760-635-2345'''.<br />
<br />
=== Third Party Components ===<br />
==== Perl ====<br />
Many of our additional test utilities and libraries require perl support on the host. In particular, we require:<br />
* Distribution of [http://activestate.com/Products/activeperl/ ActiveState perl] '''5.8.8.822''', or a later build of 5.8.x perl. We '''DO NOT''' support perl version 5.10.x at this time due to some bugs in the script component support in perl 5.10. You can download perl distributions from [http://downloads.activestate.com/ActivePerl/Windows/ ActiveState]). These distributions include the PerlScript engine that is required for use with STRIDE.<br />
* The following additional perl packages, which can all be installed using the [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html Perl Package Manager] (PPM) that comes with ActiveState perl.<br />
**Win32::API<br />
**Win32::GUI<br />
**Win32::GuiTest<br />
**Win32::ToolHelp<br />
**XML::DOM<br />
**Config::IniFiles<br />
**Getopt::Long<br />
**NET::DNS<br />
**Log::Handler<br />
The simplest way to install these packages is via the command line interface to PPM, e.g<br />
CMD> ppm install win32-api<br />
(change the last argument accordingly for each required package)<br />
<br />
'''Note:''' Due to bandwidth issues at ActiveState, PPM attempts may fail intermittently. If so, please re-try. You may also try adding a ppm repository:<br />
CMD> ppm repo add http://www.bribes.org/perl/ppm<br />
(change the last argument by specifying [http://win32.perl.org/wiki/index.php?title=PPM_Repositories any other repository])<br />
<br />
'''Note:''' PPM uses HTTP to communicate with repositories -- if your HTTP connections require a proxy server, refer to [http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/ActivePerl-faq2.html#ppm_and_proxies the PPM documentation] for information about setting the proxy.<br />
<br />
Verify all the packages have been installed via PPM<br />
CMD> ppm list<br />
<br />
We provide a perl script, ''TestInstallOfPerl.pl'', that can be used to validate the version and packages that you have installed. This script is available in ''%STRIDE_DIR%/Scripts'' folder. Run this script from a command prompt by typing <tt>perl TestInstallOfPerl.pl</tt>. On a properly configured system, it will produce results like:<br />
<br />
************************************************************<br />
Perl/System prerequisites check<br />
************************************************************<br />
OK: Perl version looks good (5.010000).<br />
OK: Package Win32::API looks good.<br />
OK: Package Win32::GUI looks good.<br />
OK: Package Win32::GuiTest looks good.<br />
OK: Package Win32::ToolHelp looks good.<br />
OK: Package XML::DOM looks good.<br />
OK: Package Config::IniFiles looks good.<br />
OK: Package Getopt::Long looks good.<br />
OK: Package NET::DNS looks good.<br />
OK: Package Log::Handler looks good.<br />
OK: Prerequisites validation successful.<br />
************************************************************<br />
<br />
Note: For the later 5.8 versions of Perl, you may see several lines of debug code above the line that verifies the NET::DNS package. This is debugging code is not a sign of unsuccessful installation and can be ignored. <br />
<br />
You should address any errors that are reported before proceeding. If you prefer to install perl '''after''' installing STRIDE, you '''must''' run this script after both are installed to verify the packages and perform the necessary STRIDE component registrations.<br />
<br />
== STRIDE Installation ==<br />
STRIDE is usually installed in the '''C:\STRIDE''' directory. Installing the core components will provide everything needed to run STRIDE on the host. <br />
<br />
'''Step-by-step instructions:'''<br />
<br />
# Exit all other Windows applications prior to beginning the STRIDE installation.<br />
# If you haven't already done so, obtain a current copy of StrideSetup.exe from you project's Basecamp site.<br />
# Select and open '''StrideSetup.exe'''.<br />
# When the Install Wizard appears, click '''Next'''.<br />
# On the '''License Agreement''' screen, click '''I Agree''' if you agree with the terms of the license and to continue the installation.<br> '''Note:''' Clicking '''No''' will terminate the installation process.<br />
# Click '''Install''' to install the Core Components, which provides the full installation of STRIDE.<br />
# When the installation is complete, click '''Finish'''. <br />
<br />
Once the installation is complete, you must have your '''license''' information ready before starting STRIDE. If you have an evaluation or node-locked license, place the license file in '''C:\STRIDE\lic''' before launching STRIDE Studio. If you are using a '''floating license''', you will be prompted for the location of the license server when you first start STRIDE. After your license setup is complete, you are ready to begin Integrating STRIDE into your Target environment.<br />
<br />
''It is highly recommended to run through the '''[[Hello_Stride_Sample | Hello Stride Sample]]''' after completing the Desktop installation.''<br />
<br />
== Conducting an unattended installation ==<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently install STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\TEMP" C:\TEMP\StrideSetup.exe /S<br />
<br />
'''Note:''' The statement above assumes that '''StrideSetup.exe''' resides in C:\TEMP; you may need to change this path to match your actual StrideSetup.exe location.<br />
<br />
== Uninstalling Host ==<br />
<br />
'''Method 1 (via Control Panel)<br />
# From the '''Start''' menu, select '''Control Panel'''.<br />
# Double-click '''Add or Remove Programs'''.<br />
# Select '''Stride''', then click '''Change/Remove'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 2 (via STRIDE Program Folder)<br />
# From the '''Start''' menu, go to '''STRIDE 3.0''' Program folder.<br />
# Select '''STRIDE Uninstall'''.<br />
# When prompted, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
'''Method 3 (via STRIDE Installation Folder)<br />
# Open the '''STRIDE installation folder''' (typically C:\STRIDE).<br />
# Go to '''uninstall''' folder.<br />
# Select and open '''STRIDEUninstall.exe'''.<br />
# When the Install Wizard appears, click '''Yes'''.<br />
# When the uninstall is complete, click '''Close'''.<br />
<br />
=== Conducting an unattended uninstallation ===<br />
The STRIDE installer supports silent (unattended) installation and uninstallation. To silently uninstall STRIDE, complete the following steps:<br />
<br />
# Open a DOS window.<br />
# Type start /WAIT /D"C:\STRIDE\uninstall" C:\STRIDE\uninstall\StrideUninstall.exe "/S _?=C:\STRIDE"<br />
<br />
<br />
[[Category:Installation]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Units_Overview&diff=8950Test Units Overview2009-01-22T21:00:19Z<p>Jaimeg: /* Floating Point Macros */</p>
<hr />
<div>== Introduction ==<br />
<br />
STRIDE enables testing of C/C++ code through the use of xUnit-style test units. Test units can be written by developers, captured using an SCL pragma, and executed from the host. STRIDE facilitates the execution of some or all of the test units by automatically creating entry points for the execution of test units on the target. <br />
<br />
== Using test units ==<br />
<br />
=== Prerequisites ===<br />
<br />
see [[Desktop Installation#Third Party Components|Perl requirements]]. <br />
<br />
===How to get started (Overview)===<br />
<br />
The required steps to get started with writing test units are as follows:<br />
<br />
<ol><br />
<li>Create a new Studio workspace (or open an existing one).</li><br />
<li>Set the workspace to compile in C++ mode (In Studio, choose Tools->Settings->Compile as Cpp).</li><br />
<li>Write a test unit. You may create a C++ test class or a C test function as your test unit. Click '''[[Test_Units#Test_Unit_Requirements|here]]''' for more information on creating test units.</li><br />
To implement a test unit as a test class:<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int test1(void) { return 0;} // PASS<br />
int test2(void) { return 23;} // FAIL <>0<br />
};<br />
<br />
#pragma scl_test_class(Simple)<br />
</source><br />
Or, as a test function:<br />
<source lang=cpp><br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int test1(void) <br />
{<br />
return 0; // PASS<br />
}<br />
<br />
int test1(void) <br />
{<br />
return 23; // FAIL <>0<br />
}<br />
<br />
#pragma scl_test_flist("Simple", test1, test2)<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
<li>Compile the workspace & review the '''Simple''' interface in the Studio Interface tab</li><br />
<li>Create a script to generate the Intercept Module(IM) '''after''' the compilation step.<br />
:For the simple STUB generation required for test unit execution, you can use the following code</li><br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE qw(in);<br />
Win32::OLE->Option(Warn => 3);<br />
my $intercept = $main::studio->Workspace->Intercept; <br />
$intercept->{Path} = $main::studio->Workspace->Path;<br />
$intercept->{Name} = $main::studio->Workspace->Name;<br />
map {$intercept->Item($_)->{Stub} = 1} (0..($intercept->Count - 1));<br />
$intercept->Create(); <br />
</source><br />
<li>Optionally add custom scripts to automate the building and executing your application.</li><br />
<li>Ensure that the Studio workspace include path contains the location to all of your test unit declaration (header) files.</li><br />
<li>Once you have created one or more test units, ensure the following:<br />
:* Workspace is compiled and saved<br />
:* Intercept Module is generated (Stubs for all Test Units)<br />
:* Target application re-built<br />
:* Target application downloaded & started<br />
:* STRIDE Connected to Target<br />
</li><br />
<br />
<li>If your application is running, you can start executing test units.<br />
:* You can test-execute individual test units interactively using the '''Studio interface''' view. To do this, open the user interface view corresponding to the test unit you would like to execute, then call it. The return values will indicate how many tests produced each of four (4) result types. Furthermore, the input to the entry point will allow you to select all methods for execution (the default) or individual methods via a dropdown list of enumerated values.<br />
:* Once you are confident that the test units are behaving as expected, you can generate one or more execution scripts using the '''Script Wizard'''. Sample '''[[templates]]''' for executing test unit entry points are provided in the %STRIDE_DIR%\templates\Script Wizard directory.<br />
:* When writing scripts to execute test units, the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection is a powerful tool for test unit execution and reporting, and for obtaining test results.</li><br />
<li>For integration with larger regression test workspaces, we recommend that developers check in their test unit code and, optionally, the template-generated scripts that can be used to execute their test units.</li><br />
</ol><br />
<br />
===Pragmas for Test Units===<br />
STRIDE supports three pragmas for capturing and qualifying test units: <br />
<br />
*'''<code>scl_test_class ( class-name )</code>''': Declares a test class as captured. Once captured, STRIDE will generate the appropriate code for executing the test methods in the class. See the [[scl_test_class|scl_test_class page]] for more information.<br />
*'''<code>scl_test_flist ( test-unit-name , test-function-name { , test-function-name } )</code>''': Declares a test unit as captured, by the specified test-unit-name. One or more functions (test methods) are associated with the test unit. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_flist|scl_test_flist page]] for more information.<br />
*'''<code>scl_test_cclass ( struct-name , init-function-name { , deinit-function-name } )</code>''': Declares a test unit as captured. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_cclass|scl_test_cclass page]] for more information.<br />
*'''<code>scl_test_setup ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a setup fixture for the test unit. If specified, the setup method will be called before the execution of each test method. See the [[scl_test_setup|scl_test_setup page]] for more information.<br />
*'''<code>scl_test_teardown ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a teardown fixture for the test unit. If specified, the teardown method will be called after the execution of each test method. See the [[scl_test_teardown|scl_test_teardown page]] for more information.<br />
<br />
== Test Unit Requirements ==<br />
<br />
Several variations on typical xUnit-style test units are supported. The additional supported features include: <br />
<br />
*Test status can be set using STRIDE Runtime APIs ''or'' by specifying simple return types for test methods. <br />
*Simple return types: 0 = PASS; &lt;&gt; 0 = FAIL <br />
*void return type with no explict status setting is assumed PASS <br />
*Test writers can create additional child suites and tests at runtime by using Runtime APIs. <br />
*We do not rely on exceptions for reporting of status.<br />
<br />
The STRIDE test class framework has the following requirements of each test class: <br />
<br />
*The test class must have a suitable default (no-argument) constructor. <br />
*The test class must have one or more public methods suitable as test methods. Allowable test methods always take no arguments (void) and return either void or simple integer types (int, short, long, char or bool). At this time, we do not allow typedef types or macros for the return values specification. <br />
*the scl_test_class pragma must be applied to the class.<br />
<br />
<br />
=== Simple example using return values for status ===<br />
==== Using a Test Class ====<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int tc_Int_ExpectPass(void) {return 0;}<br />
int tc_Int_ExpectFail(void) {return -1;}<br />
bool tc_Bool_ExpectPass(void) {return true;}<br />
bool tc_Bool_ExpectFail(void) {return false;}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(Simple)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int tf_Int_ExpectPass(void) {return 0;}<br />
int tf_Int_ExpectFail(void) {return -1;}<br />
bool tf_Bool_ExpectPass(void) {return true;}<br />
bool tf_Bool_ExpectFail(void) {return false;}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("Simple", tf_Int_ExpectPass, tf_Int_ExpectFail, tf_Bool_ExpectPass, tf_Bool_ExpectFail)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using runtime test service APIs ===<br />
==== Using a Test Class ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class RuntimeServices_basic {<br />
public: <br />
void tc_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(RuntimeServices_basic)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
void tf_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tf_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tf_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("RuntimeServices_basic", tf_ExpectPass, tf_ExpectFail, tf_ExpectInProgress)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using srTest base class ===<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class MyTest : public stride::srTest {<br />
public:<br />
void tc_ExpectPass(void) <br />
{<br />
testCase.AddComment("this test should pass");<br />
testCase.SetStatus(srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
testCase.AddComment("this test should fail");<br />
testCase.SetStatus(srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
testCase.AddComment("this test should be in progress");<br />
}<br />
int tc_ChangeMyName(void) <br />
{<br />
testCase.AddComment("this test should have name = MyChangedName");<br />
testCase.SetName("MyChangedName");<br />
return 0;<br />
}<br />
int tc_ChangeMyDescription(void) <br />
{<br />
testCase.AddComment("this test should have a description set");<br />
testCase.SetDescription("this is my new description");<br />
return 0;<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(MyTest)<br />
#endif<br />
</source><br />
<br />
== Runtime Test Services ==<br />
<br />
The Runtime Test Services (declared in srTest.h) are a set of APIs in the STRIDE Runtime that facilitate the writing of target based test code. These APIs make up an optional portion of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. These APIs also allow target test code to create additional test suites and test cases dynamically at runtime. <br />
<br />
There are 2 alternate ways of accessing these APIs: through C-based functions, or through a C++ base class from which you may derive your C++ test class. These are discussed below in C Test Functions, and C++ Test Classes sections below.<br />
<br />
=== C Test Functions ===<br />
<br />
The following C APIs are provided: <br />
<br />
*'''[[#srTestSuiteAddSuite|srTestSuiteAddSuite]]''': creates an additional sub-suite at runtime. <br />
*'''[[#srTestSuiteSetName|srTestSuiteSetName]]''': sets the name of the specified suite. <br />
*'''[[#srTestSuiteSetDescription|srTestSuiteSetDescription]]''': sets the description of the specified suite. <br />
*'''[[#srTestSuiteAddTest|srTestSuiteAddTest]]''': creates an additional test case at runtime. <br />
*'''[[#srTestCaseSetName|srTestCaseSetName]]''': sets the name of the specified test case. <br />
*'''[[#srTestCaseSetDescription|srTestCaseSetDescription]]''': sets the description of the specified test case. <br />
*'''[[#srTestCaseAddComment|srTestCaseAddComment]]''': adds a comment to the specified test case. <br />
*'''[[#srTestCaseSetStatus|srTestCaseSetStatus]]''': explicitly sets the status for the specified test case.<br />
*'''[[#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]]''': creates an annotation at runtime. <br />
*'''[[#srTestAnnotationAddComment|srTestAnnotationAddComment]]''': adds a comment to the specified annotation.<br />
<br />
<br />
==== srTestSuiteAddSuite ====<br />
The srTestSuiteAddSuite() routine is used to add a new test suite to the specified test suite.<br />
<source lang=c><br />
srTestSuiteHandle_t srTestSuiteAddSuite(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test suite is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test suite. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
|srTestSuiteHandle_t <br />
| Handle of the newly created test suite. srTEST_SUITE_INVALID indicates failure to create test suite.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addSuite(void)<br />
{<br />
srTestSuiteHandle_t subSuite =<br />
srTestSuiteAddSuite(srTEST_SUITE_DEFAULT, "tf Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addSuite)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetName ====<br />
The srTestSuiteSetName() routine is used to set the name of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetName(srTestSuiteHandle_t tTestSuite, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_setName(void)<br />
{<br />
srTestSuiteSetName(srTEST_SUITE_DEFAULT, "Setting name for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetDescription ====<br />
The srTestSuiteSetDescription() routine is used to set the description of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetDescription(srTestSuiteHandle_t tTestSuite, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include "srtest.h"<br />
void tfsuite_setDescription(void)<br />
{<br />
srTestSuiteSetDescription(srTEST_SUITE_DEFAULT,<br />
"Setting description for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddTest ====<br />
The srTestSuiteAddTest() routine is used to add a new test case to the specified test suite.<br />
<source lang=c><br />
srTestCaseHandle_t srTestSuiteAddTest(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test case is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test case. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCaseHandle_t <br />
| Handle of the newly created test case. srTEST_CASE_INVALID indicates failure to create test case.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
void tfsuite_addTest(void)<br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "dynamic test case %d", count);<br />
srTestCaseHandle_t test = srTestSuiteAddTest(srTEST_SUITE_DEFAULT, szName);<br />
srTEST_ADD_COMMENT_WITH_LOCATION(test, "this is a dynamic test case");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addTest)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetName ====<br />
The srTestCaseSetName() routine is used to set set the name of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetName(srTestCaseHandle_t tTestCase, const srCHAR *szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setName(void)<br />
{<br />
srTestCaseSetName(srTEST_CASE_DEFAULT, "Setting name for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetDescription ====<br />
The srTestCaseSetDescription() routine is used to set the description of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetDescription(srTestCaseHandle_t tTestCase, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setDescription(void)<br />
{<br />
srTestCaseSetDescription(srTEST_CASE_DEFAULT,<br />
"Setting description for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseAddComment ====<br />
The srTestCaseAddComment() routine is used to add a comment (aka a log) to be reported with the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseAddComment(srTestCaseHandle_t tTestCase, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_addComment(void)<br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_addComment)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatus ====<br />
The srTestCaseSetStatus() routine is used to set the result of test case.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input <br />
| The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatus(void)<br />
{<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatus)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatusEx ====<br />
The srTestCaseSetStatusEx() routine is used to set the result of test case and allow specification of an extendedFailureCode.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration, srLONG lExtendedFailureCode)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test. dwDuration Input The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|-<br />
| lExtendedFailureCode <br />
| Input <br />
| The Stride framework uses the extendedFailureCode to capture the numeric results of test method when the test method fails via a numeric (non-void, nonbool) return type.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatusEx(void)<br />
{<br />
srTestCaseSetStatusEx(srTEST_CASE_DEFAULT, srTEST_FAIL, 0, -5);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatusEx)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddAnnotation ====<br />
The srTestSuiteAddAnnotation() routine is used to add a new annotation to the specified test suite.<br />
<source lang=c><br />
srTestAnnotationHandle_t srTestSuiteAddAnnotation(rTestSuiteHandle_t tParent, srTestAnnotationLevel_e eLevel, const srCHAR * szName, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new annotation is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| eLevel<br />
| Input <br />
| Annotation level. Cannot be empty.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of annotation. If null, the default host naming scheme will be used.<br />
|-<br />
| szDescr<br />
| Input <br />
| Pointer to a null-terminated string representing the description of annotation. If null, description will be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotationHandle_t <br />
| HHandle of the newly created annotation. srTEST_ANNOTATION_INVALID indicates failure to create annotation.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addAnnotation(void) <br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "annotation %d", count);<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
szName,<br />
"description of annotation");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addAnnotation)<br />
#endif<br />
</source><br />
<br />
==== srTestAnnotationAddComment ====<br />
The srTestAnnotationAddComment() routine is used to add a comment (aka a log) to be reported with the specified annotation.<br />
<source lang=c><br />
srWORD srTestAnnotationAddComment(srTestAnnotationHandle_t tTestAnnotation, const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestAnnotation<br />
| Input<br />
| Handle to an annotation created using srTestSuiteAddAnnotation.<br />
|-<br />
| szLabel<br />
| Input <br />
| Pointer to a null-terminated string for the label. If null, the default label will be applied.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuiteAnnotation_addComment(void) <br />
{<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
“annot”,<br />
“annot description”);<br />
srTestAnnotationAddComment(annot,<br />
srNULL,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuiteAnnotation_addComment)<br />
#endif<br />
</source><br />
<br />
=== C++ Test Classes ===<br />
The Runtime Test Services C APIs work equally well from C test functions and C++ test classes. If, however, you are using C++ it might be more convinient for you to derive your C++ test classes from the Runtime Test Services C++ base class, ''srTest''. That way you will have access to a set of simpler to use C++ classes. <br />
<br />
The following C++ classes are provided: <br />
* '''[[#class srTest|class srTest]]''' - base test class<br />
* '''[[#class srTestSuite|class srTestSuite]]''' - represents a test suite<br />
* '''[[#class srTestCase|class srTestCase]]''' - represents a test case<br />
* '''[[#class srTestAnnotation|class srTestAnnotation]]''' - represents a test annotation<br />
<br />
==== class srTest ====<br />
The srTest class provides two Member Objects:<br />
*''testSuite'' of class srTestSuite <br />
*''testCase''of class srTestCase<br />
<br />
==== class srTestSuite ====<br />
The srTest class provides the folowing methods:<br />
<br />
===== method AddSuite =====<br />
The AddSuite method is used to add a new test suite.<br />
<source lang=cpp><br />
srTestSuite AddSuite(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
|szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test suite. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestSuite <br />
| Newly created test suite class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
stride::srTestSuite suite = testSuite.AddSuite("tc Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test suite.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetName(void);<br />
};<br />
<br />
void srtest_class::suiteSetName(void)<br />
{<br />
testSuite.SetName("Setting name for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test suite.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|- <br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetDescription(void);<br />
};<br />
<br />
void srtest_class::suiteSetDescription(void)<br />
{<br />
testSuite.SetDescription("Setting description for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddTest =====<br />
The AddTest method is used to add a new test case to test suite.<br />
<source lang=cpp><br />
srTestCase AddTest(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test case. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCase <br />
| Newly created test case class.<br />
|}<br />
<br><br />
'''Example'''<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
const std::string prefix("dynamic test case ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strm;<br />
strm << prefix << count;<br />
stride::srTestCase tc = testSuite.AddTest(strm.str().c_str());<br />
tc.AddComment("this is a dynamic test case");<br />
tc.SetStatus(srTEST_PASS);<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddAnnotation =====<br />
The AddAnnotation method is used to add a new annotation to test suite.<br />
<source lang=cpp><br />
srTestAnnoation AddAnnotation(srTestAnnotationLevel_e eLevel, const srCHAR * szName = srNULL, const srCHAR * szDescr = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eLevel<br />
| Input<br />
| Annotation level. Cannot be empty.<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of annotation. If empty, the default host naming scheme will be used.<br />
|- <br />
| szDescr<br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the description of annotation. If empty, the description will be blank.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotation<br />
| Newly created annotation class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddAnnotation(void);<br />
};<br />
<br />
void srtest_class::suiteAddAnnotation(void) <br />
{<br />
const std::string prefixName("annotation ");<br />
const std::string prefixDescr("description of annotation ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strmName;<br />
std::stringstream strmDescr;<br />
strmName << prefixName << count;<br />
strmDescr << prefixDescr << count;<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
strmName.str().c_str(),<br />
strmDescr.str().c_str());<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestCase ====<br />
The srTestCase class provides the following methods:<br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test case.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetName(void);<br />
};<br />
<br />
void srtest_class::caseSetName(void)<br />
{<br />
testCase.SetName("Setting name for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test case.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetDescription(void);<br />
};<br />
<br />
void srtest_class::caseSetDescription(void)<br />
{<br />
testCase.SetDescription("Setting description for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to test case.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseAddComment(void);<br />
};<br />
<br />
void srtest_class::caseAddComment(void)<br />
{<br />
testCase.AddComment("this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetStatus =====<br />
The SetStatus method is used to set the result of the default test case.<br />
<source lang=cpp><br />
srWORD SetStatus(srTestStatus_e eStatus, srDWORD dwDuration = 0)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input (Optional)<br />
| The duration of the test in clock ticks. The default is 0.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetStatus(void);<br />
};<br />
<br />
void srtest_class::caseSetStatus(void)<br />
{<br />
testCase.SetStatus(srTEST_INPROGRESS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestAnnotation ====<br />
The srTestAnnotation class provides the following methods:<br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to an annotation created under a test suite.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szLabel<br />
| Input <br />
| Pointer to null-terminated string for the label. If null, the default label will be applied.<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAnnotationAddComment(void);<br />
};<br />
<br />
void srtest_class::suiteAnnotationAddComment(void)<br />
{<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
“annot”,<br />
“annot description”);<br />
ta.AddComment("this comment on annotation should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
Refer to the [[Media:s2sSCLReferenceGuide.pdf|SCL Reference Guide]] or the [[Media:s2sRuntime.pdf|Runtime Developer's Guide]] for detailed information about any of these APIs.<br />
<br />
== ASSERT/EXPECT Macros ==<br />
<br />
The STRIDE Test Unit implementation also provides a set of Test Macros available for use within test methods. The macros are optional - you are not required to use them in your test units. They provide shortcuts for testing assertions and automatic report annotation in the case of failures. <br />
<br />
The macros can currently only be used in C++ test unit code. <br />
<br />
=== General guidelines for all macros ===<br />
<br />
srEXPECT_xx macros will set the current test case to fail (if it hasn’t already been set) and produce an annotation in the report if the expectation fails. If the expectation succeeds, there is no action. <br />
<br />
srASSERT_xx macros will set the current test case to fail (if it hasn’t already been set) and insert an annotation into the report if the assertion fails. In addition, a return from the current function will occur. srASSERT_xx macros can only be used in test functions which return void. If the assertion succeeds there is no action. <br />
<br />
The report annotation produced by a failed macro always includes the source file and line along with details about the condition that failed and the failing values. <br />
<br />
<nowiki>All the macros support the adding to the report annotations using the << operator. For example:</nowiki><br />
<br />
srEXPECT_TRUE( a != <nowiki>b) << “My custom message”; </nowiki><br />
<br />
<nowiki>As delivered, the macros will support stream operator annotations using all the numeric types, char* and s2String. The user may create custom types to be used a report annotation by providing an implementation of the << operator for their custom type. The details are explained in a section below. </nowiki><br />
<br />
=== Boolean Macros ===<br />
The boolean macros take a single condition expression, ''cond'', that evaluates to an integral type or bool. The condition will be evaluated once. if ''cond'' evaluates to non-zero the assertion or expectation fails. When a failure occurs the report will be annotated. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE(''cond'');<br />
| srASSERT_TRUE(''cond'');<br />
| ''cond'' is true<br />
<br />
|-<br />
| srEXPECT_FALSE(''cond'');<br />
| srASSERT_FALSE(''cond'');<br />
| ''cond'' is false<br />
<br />
|}<br />
<br />
=== Comparison Macros ===<br />
<br />
Comparison macros take two operands and compare them using the indicated operator. The comparison macros will work for primitive types as well as objects that have the corresponding comparison operator implemented. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ(''val1'', ''val2'');<br />
| srASSERT_EQ(''val1'', ''val2'');<br />
| ''val1'' == ''val2''<br />
<br />
|-<br />
| srEXPECT_NE(''val1'', ''val2'');<br />
| srASSERT_NE(''val1'', ''val2'');<br />
| ''val1'' != ''val2''<br />
<br />
|-<br />
| srEXPECT_LT(''val1'', ''val2'');<br />
| srASSERT_LT(''val1'', ''val2'');<br />
| ''val1''<nowiki> < </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_LE(''val1'', ''val2'');<br />
| srASSERT_LE(''val1'', ''val2'');<br />
| ''val1''<nowiki> <= </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_GT(''val1'', ''val2'');<br />
| srASSERT_GT(''val1'', ''val2'');<br />
| ''val1'' > ''val2''<br />
<br />
|-<br />
| srEXPECT_GE(''val1'', ''val2'');<br />
| srASSERT_GE(''val1'', ''val2'');<br />
| ''val1'' >= ''val2''<br />
<br />
|}<br />
<br />
=== C String Comparison Macros ===<br />
<br />
C String Comparison Macros are intended only for use with C-style zero terminated strings. The strings can be char or wchar_t based. In particular, these macros should not be used for object of one or other string class, since such classes have overloaded comparison operators. The standard comparison macros should be used instead. <br />
<br />
* The length of a string displayed in the report annotation message is controllable via the following macro: srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY (found in srtestmacros.h). If a string value is truncated because of the length limit, the text "...(trunc)" will always appear next to it. <br />
* An empty string will appear in error message output as “”. A null string will appear as NULL with no surrounding quotes. Otherwise all output strings are quoted. <br />
* The type of str1 and str2 must be compatible with const char* or const wchar_t*. <br />
<br />
<br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ(''str1'', ''str2'');<br />
| srASSERT_STREQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content<br />
<br />
|-<br />
| srEXPECT_STRNE(''str1'', ''str2'');<br />
| srASSERT_STRNE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ(''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content, ignoring case.<br />
<br />
|-<br />
| srEXPECT_STRCASENE(''str1'', ''str2'');<br />
| srASSERT_STRCASENE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content, ignoring case.<br />
<br />
|}<br />
<br />
=== Exception Macros ===<br />
Exception macros are used to ensure that expected exceptions are thrown. They require exception support from the target compiler. If the target compiler does not have exception support the macros cannot be used and must be disabled. The support can be disabled via the macro srCFG_TEST_MACROS_EXCEPTIONS_ON found in srtestmacros.h. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW(statement, ex_type);<br />
| srASSERT_THROW(statement, ex_type);<br />
| ''statement'' throws an exception of type ''ex_type''<br />
<br />
|-<br />
| srEXPECT_THROW_ANY(''statement'');<br />
| srASSERT_THROW_ANY(''statement'');<br />
| ''statement'' throws an exception (type not important)<br />
<br />
|-<br />
| srEXPECT_NO_THROW(''statement'');<br />
| srASSERT_NO_THROW(''statement'');<br />
| ''statement'' does not throw an exception<br />
<br />
|}<br />
<br />
=== Predicate Macros ===<br />
Predicate macros allow user control over the pass/fail decision making in a macro. A predicate is a function returning bool that is implemented by the user but passed to the macro. Other arguments for the predicate are also passed to the macro. The macros allow for predicate functions with up to four parameters. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1(''pred'', ''val1'')<br />
| srASSERT_PRED1(''pred'', ''val1'')<br />
| ''pred''(''val1'') returns true<br />
<br />
|-<br />
| srEXPECT_PRED2(''pred'', ''vall'', ''val2'')<br />
| srASSERT_PRED2(''pred'', ''vall'', ''val2'')<br />
| ''pred''(''val1'', ''val2'') returns true<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
| <br />
<br />
|}<br />
All predicate macros require a predicate function function which returns bool. The predicate macros allow functions with one to 4 parameters. Following are the report annotations resulting from expectation or assertion failures.<br />
<br />
=== Floating Point Macros ===<br />
<br />
Floating point macros are for comparing equivalence (or near equivalence) of floating point numbers. These macros are necessary since because equivalence comparisons for floating point numbers will often fail due to round-off errors. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Floating Point Macros'''<br />
<br />
|-<br />
| srEXPECT_NEAR(val1, val2, epsilon);<br />
| srASSERT_NEAR(val1, val2, epsilon);<br />
| The absolute value of the difference between val1 and val2 is epsilon.<br />
|}<br />
<br />
=== Dynamic Test Case Macros ===<br />
The macros presented so far are not capable of dealing with dynamic test cases. In order to handle dynamic test cases, each of the macros requires another parameter which is the test case to report against. Other than this, these macros provide exactly equivalent functionality to the non-dynamic peer. The dynamic macros are listed below. All require a test case, value of type srTestCaseHandle_t from srtest.h, to be passed as the first parameter).<br />
<br />
{| class="prettytable"<br />
| '''''Nonfatal assertion'''''<br />
| '''''Fatal Assertion'''''<br />
<br />
|-<br />
| colspan="2" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE_DYN(tc, ''cond'');<br />
| srASSERT_TRUE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| srEXPECT_FALSE_DYN(tc, ''cond'');<br />
| srASSERT_FALSE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| colspan="2" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_EQ_DYN(tc, ''expect'', ''val'');<br />
<br />
|-<br />
| srEXPECT_NE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_NE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| colspan="2" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| colspan="2" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW_DYN(statement, ex_type);<br />
| srASSERT_THROW_DYN(tc, statement, ex_type);<br />
<br />
|-<br />
| srEXPECT_THROW_ANY_DYN(tc, ''statement'');<br />
| srASSERT_THROW_ANY_DYN(tc, ''statement'');<br />
<br />
|-<br />
| srEXPECT_NO_THROW_DYN(tc, ''statement'');<br />
| srASSERT_NO_THROW_DYN(tc, ''statement'');<br />
<br />
|-<br />
| colspan="2" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
| srASSERT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
<br />
|-<br />
| srEXPECT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
| srASSERT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
<br />
|-<br />
| colspan="2" | '''Floating Point'''<br />
<br />
|-<br />
| srEXPECT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
| srASSERT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
<br />
|}<br />
<br />
=== Overloading The << operator for report annotation ===<br />
<nowiki>The user of the asserting macros package may overload the << operator in order to annotate reports using a custom class. An example is below. </nowiki><br />
<br />
<nowiki>The following will compile and execute successfully given that the << operator is overloaded as shown:</nowiki><br />
<br />
<pre><br />
MyCustomClass custom(34); <br />
<br />
srEXPECT_FALSE(true) << custom;<br />
<br />
// MyCustomClass implementation<br />
class MyCustomClass<br />
{<br />
public:<br />
MyCustomClass(int i) : m_int(i) {}<br />
<br />
private: <br />
int m_int; <br />
friend stride::Message& operator<< <br />
( stride::Message& ss, const MyCustomClass& obj);<br />
}; <br />
<br />
stride::Message& operator<<(stride::Message& ss, const MyCustomClass& obj)<br />
{<br />
<br />
// format the internals as a string and send on<br />
char buf[20]; <br />
sprintf(buf, "%d", obj.m_int); <br />
ss << buf;<br />
return ss;<br />
}<br />
</pre><br />
<br />
=== Test Macro Configuration ===<br />
<br />
The Test Macros are implemented in C++. Because target support for use of the standard libraries and exceptions varies across targets the macro implementation can be configured. <br />
<br />
==== Configuring Test Macros When Exceptions Not Available ====<br />
If the target compiler does not support exceptions (or they are disabled) the Exception Macros must be disabled. This is accomplished by setting srCFG_TEST_MACROS_EXCEPTIONS_ON to 0 in the file srtestmacros.h.<br />
<br />
==== Configuring Test Macros When C++ Standard Library is Not Available ====<br />
If the C++ standard library can be used within the target code, the test macro implementation uses std::string and std::stringstream. If the classes are not available on the target, then an alternate, custom implementation that relies only on C library support can be used. <br />
<br />
The choice is configured via srCFG_TEST_MACROS_USE_STANDARD_LIB found within srtestmacros.h<br />
<br />
==== Configuring Report Annotation for C-String Comparisons ====<br />
<br />
The C-String comparison macros are used to compare strings. When comparisons fail, the values involved in the failed comparison are normally displayed in the report. If the strings are very long, this is probably not desirable. It is possible to constrain the maximum length of the displayed strings using srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY. String values longer than this value will be truncated in report annotations. <br />
<br />
<br />
== Scripting a Test Unit ==<br />
<br />
To automate the execution and reporting of a Test Unit a script is required. Scripts can be written by hand or automatically generated using the Script Wizard and a corresponding template script. A scripting tool for executing a test unit is the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection. An [[AutoScript#ascript.TestUnits.Item|Ascript TestUnit]] object assembles all of the reporting information for the test unit and its corresponding test methods. <br />
<br />
*Require useage of the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection <br />
*Can be written by hand (refer below) <br />
*Can leverage [[Templates|Templates]] via the Script Wizard <br />
*Order of multiple test units dictated by SUID assignment<br />
<br />
<br> <br />
<br />
=== JScript example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=javascript><br />
// Ensure test unit exists<br />
if (ascript.TestUnits.Item("Simple") != null) <br />
ascript.TestUnits.Item("Simple").Run();<br />
</source><br />
<br />
=== Perl example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
my $tu = $main::ascript->TestUnits->Item("Simple");<br />
if (defined $tu) {<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
=== JScript example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=javascript><br />
var Units = ["Simple1","Simple2"];<br />
<br />
// iterate through each function<br />
for (i in Units)<br />
{<br />
var tu = ascript.TestUnits.Item(Units[i]);<br />
if ( tu&nbsp;!= null ) <br />
tu.Run();<br />
}<br />
</source><br />
<br />
=== Perl example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
# initialize an array with all selected function names<br />
my @UnitNames = ("Simple1","Simple2");<br />
foreach (@UnitNames) { <br />
my $tu = $main::ascript->TestUnits->Item($_->[1]);<br />
die "TestUnit not found: $_->[1]\n" unless (defined $tu);<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
[[Category:Test Units]]<br />
[[Category:Reference]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Units_Overview&diff=8948Test Units Overview2009-01-22T20:44:39Z<p>Jaimeg: /* Predicate Macros */</p>
<hr />
<div>== Introduction ==<br />
<br />
STRIDE enables testing of C/C++ code through the use of xUnit-style test units. Test units can be written by developers, captured using an SCL pragma, and executed from the host. STRIDE facilitates the execution of some or all of the test units by automatically creating entry points for the execution of test units on the target. <br />
<br />
== Using test units ==<br />
<br />
=== Prerequisites ===<br />
<br />
see [[Desktop Installation#Third Party Components|Perl requirements]]. <br />
<br />
===How to get started (Overview)===<br />
<br />
The required steps to get started with writing test units are as follows:<br />
<br />
<ol><br />
<li>Create a new Studio workspace (or open an existing one).</li><br />
<li>Set the workspace to compile in C++ mode (In Studio, choose Tools->Settings->Compile as Cpp).</li><br />
<li>Write a test unit. You may create a C++ test class or a C test function as your test unit. Click '''[[Test_Units#Test_Unit_Requirements|here]]''' for more information on creating test units.</li><br />
To implement a test unit as a test class:<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int test1(void) { return 0;} // PASS<br />
int test2(void) { return 23;} // FAIL <>0<br />
};<br />
<br />
#pragma scl_test_class(Simple)<br />
</source><br />
Or, as a test function:<br />
<source lang=cpp><br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int test1(void) <br />
{<br />
return 0; // PASS<br />
}<br />
<br />
int test1(void) <br />
{<br />
return 23; // FAIL <>0<br />
}<br />
<br />
#pragma scl_test_flist("Simple", test1, test2)<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
<li>Compile the workspace & review the '''Simple''' interface in the Studio Interface tab</li><br />
<li>Create a script to generate the Intercept Module(IM) '''after''' the compilation step.<br />
:For the simple STUB generation required for test unit execution, you can use the following code</li><br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE qw(in);<br />
Win32::OLE->Option(Warn => 3);<br />
my $intercept = $main::studio->Workspace->Intercept; <br />
$intercept->{Path} = $main::studio->Workspace->Path;<br />
$intercept->{Name} = $main::studio->Workspace->Name;<br />
map {$intercept->Item($_)->{Stub} = 1} (0..($intercept->Count - 1));<br />
$intercept->Create(); <br />
</source><br />
<li>Optionally add custom scripts to automate the building and executing your application.</li><br />
<li>Ensure that the Studio workspace include path contains the location to all of your test unit declaration (header) files.</li><br />
<li>Once you have created one or more test units, ensure the following:<br />
:* Workspace is compiled and saved<br />
:* Intercept Module is generated (Stubs for all Test Units)<br />
:* Target application re-built<br />
:* Target application downloaded & started<br />
:* STRIDE Connected to Target<br />
</li><br />
<br />
<li>If your application is running, you can start executing test units.<br />
:* You can test-execute individual test units interactively using the '''Studio interface''' view. To do this, open the user interface view corresponding to the test unit you would like to execute, then call it. The return values will indicate how many tests produced each of four (4) result types. Furthermore, the input to the entry point will allow you to select all methods for execution (the default) or individual methods via a dropdown list of enumerated values.<br />
:* Once you are confident that the test units are behaving as expected, you can generate one or more execution scripts using the '''Script Wizard'''. Sample '''[[templates]]''' for executing test unit entry points are provided in the %STRIDE_DIR%\templates\Script Wizard directory.<br />
:* When writing scripts to execute test units, the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection is a powerful tool for test unit execution and reporting, and for obtaining test results.</li><br />
<li>For integration with larger regression test workspaces, we recommend that developers check in their test unit code and, optionally, the template-generated scripts that can be used to execute their test units.</li><br />
</ol><br />
<br />
===Pragmas for Test Units===<br />
STRIDE supports three pragmas for capturing and qualifying test units: <br />
<br />
*'''<code>scl_test_class ( class-name )</code>''': Declares a test class as captured. Once captured, STRIDE will generate the appropriate code for executing the test methods in the class. See the [[scl_test_class|scl_test_class page]] for more information.<br />
*'''<code>scl_test_flist ( test-unit-name , test-function-name { , test-function-name } )</code>''': Declares a test unit as captured, by the specified test-unit-name. One or more functions (test methods) are associated with the test unit. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_flist|scl_test_flist page]] for more information.<br />
*'''<code>scl_test_cclass ( struct-name , init-function-name { , deinit-function-name } )</code>''': Declares a test unit as captured. Once captured, STRIDE will generate the appropriate code for executing the associated test methods. See the [[scl_test_cclass|scl_test_cclass page]] for more information.<br />
*'''<code>scl_test_setup ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a setup fixture for the test unit. If specified, the setup method will be called before the execution of each test method. See the [[scl_test_setup|scl_test_setup page]] for more information.<br />
*'''<code>scl_test_teardown ( test-unit-name , method-name )</code>''': [optional] Declares a member method to be a teardown fixture for the test unit. If specified, the teardown method will be called after the execution of each test method. See the [[scl_test_teardown|scl_test_teardown page]] for more information.<br />
<br />
== Test Unit Requirements ==<br />
<br />
Several variations on typical xUnit-style test units are supported. The additional supported features include: <br />
<br />
*Test status can be set using STRIDE Runtime APIs ''or'' by specifying simple return types for test methods. <br />
*Simple return types: 0 = PASS; &lt;&gt; 0 = FAIL <br />
*void return type with no explict status setting is assumed PASS <br />
*Test writers can create additional child suites and tests at runtime by using Runtime APIs. <br />
*We do not rely on exceptions for reporting of status.<br />
<br />
The STRIDE test class framework has the following requirements of each test class: <br />
<br />
*The test class must have a suitable default (no-argument) constructor. <br />
*The test class must have one or more public methods suitable as test methods. Allowable test methods always take no arguments (void) and return either void or simple integer types (int, short, long, char or bool). At this time, we do not allow typedef types or macros for the return values specification. <br />
*the scl_test_class pragma must be applied to the class.<br />
<br />
<br />
=== Simple example using return values for status ===<br />
==== Using a Test Class ====<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class Simple {<br />
public:<br />
int tc_Int_ExpectPass(void) {return 0;}<br />
int tc_Int_ExpectFail(void) {return -1;}<br />
bool tc_Bool_ExpectPass(void) {return true;}<br />
bool tc_Bool_ExpectFail(void) {return false;}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(Simple)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int tf_Int_ExpectPass(void) {return 0;}<br />
int tf_Int_ExpectFail(void) {return -1;}<br />
bool tf_Bool_ExpectPass(void) {return true;}<br />
bool tf_Bool_ExpectFail(void) {return false;}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("Simple", tf_Int_ExpectPass, tf_Int_ExpectFail, tf_Bool_ExpectPass, tf_Bool_ExpectFail)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using runtime test service APIs ===<br />
==== Using a Test Class ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class RuntimeServices_basic {<br />
public: <br />
void tc_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(RuntimeServices_basic)<br />
#endif<br />
</source><br />
<br />
==== Using a Test Function ====<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
void tf_ExpectPass(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); <br />
}<br />
void tf_ExpectFail(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); <br />
}<br />
void tf_ExpectInProgress(void) <br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist("RuntimeServices_basic", tf_ExpectPass, tf_ExpectFail, tf_ExpectInProgress)<br />
#endif<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
</source><br />
<br />
=== Simple example using srTest base class ===<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class MyTest : public stride::srTest {<br />
public:<br />
void tc_ExpectPass(void) <br />
{<br />
testCase.AddComment("this test should pass");<br />
testCase.SetStatus(srTEST_PASS, 0); <br />
}<br />
void tc_ExpectFail(void) <br />
{<br />
testCase.AddComment("this test should fail");<br />
testCase.SetStatus(srTEST_FAIL, 0); <br />
}<br />
void tc_ExpectInProgress(void) <br />
{<br />
testCase.AddComment("this test should be in progress");<br />
}<br />
int tc_ChangeMyName(void) <br />
{<br />
testCase.AddComment("this test should have name = MyChangedName");<br />
testCase.SetName("MyChangedName");<br />
return 0;<br />
}<br />
int tc_ChangeMyDescription(void) <br />
{<br />
testCase.AddComment("this test should have a description set");<br />
testCase.SetDescription("this is my new description");<br />
return 0;<br />
}<br />
};<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(MyTest)<br />
#endif<br />
</source><br />
<br />
== Runtime Test Services ==<br />
<br />
The Runtime Test Services (declared in srTest.h) are a set of APIs in the STRIDE Runtime that facilitate the writing of target based test code. These APIs make up an optional portion of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. These APIs also allow target test code to create additional test suites and test cases dynamically at runtime. <br />
<br />
There are 2 alternate ways of accessing these APIs: through C-based functions, or through a C++ base class from which you may derive your C++ test class. These are discussed below in C Test Functions, and C++ Test Classes sections below.<br />
<br />
=== C Test Functions ===<br />
<br />
The following C APIs are provided: <br />
<br />
*'''[[#srTestSuiteAddSuite|srTestSuiteAddSuite]]''': creates an additional sub-suite at runtime. <br />
*'''[[#srTestSuiteSetName|srTestSuiteSetName]]''': sets the name of the specified suite. <br />
*'''[[#srTestSuiteSetDescription|srTestSuiteSetDescription]]''': sets the description of the specified suite. <br />
*'''[[#srTestSuiteAddTest|srTestSuiteAddTest]]''': creates an additional test case at runtime. <br />
*'''[[#srTestCaseSetName|srTestCaseSetName]]''': sets the name of the specified test case. <br />
*'''[[#srTestCaseSetDescription|srTestCaseSetDescription]]''': sets the description of the specified test case. <br />
*'''[[#srTestCaseAddComment|srTestCaseAddComment]]''': adds a comment to the specified test case. <br />
*'''[[#srTestCaseSetStatus|srTestCaseSetStatus]]''': explicitly sets the status for the specified test case.<br />
*'''[[#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]]''': creates an annotation at runtime. <br />
*'''[[#srTestAnnotationAddComment|srTestAnnotationAddComment]]''': adds a comment to the specified annotation.<br />
<br />
<br />
==== srTestSuiteAddSuite ====<br />
The srTestSuiteAddSuite() routine is used to add a new test suite to the specified test suite.<br />
<source lang=c><br />
srTestSuiteHandle_t srTestSuiteAddSuite(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test suite is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test suite. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
|srTestSuiteHandle_t <br />
| Handle of the newly created test suite. srTEST_SUITE_INVALID indicates failure to create test suite.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addSuite(void)<br />
{<br />
srTestSuiteHandle_t subSuite =<br />
srTestSuiteAddSuite(srTEST_SUITE_DEFAULT, "tf Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addSuite)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetName ====<br />
The srTestSuiteSetName() routine is used to set the name of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetName(srTestSuiteHandle_t tTestSuite, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_setName(void)<br />
{<br />
srTestSuiteSetName(srTEST_SUITE_DEFAULT, "Setting name for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteSetDescription ====<br />
The srTestSuiteSetDescription() routine is used to set the description of the specified test suite.<br />
<source lang=c><br />
srWORD srTestSuiteSetDescription(srTestSuiteHandle_t tTestSuite, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestSuite <br />
| Input<br />
| Handle to a test suite. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test suite. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include "srtest.h"<br />
void tfsuite_setDescription(void)<br />
{<br />
srTestSuiteSetDescription(srTEST_SUITE_DEFAULT,<br />
"Setting description for default suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddTest ====<br />
The srTestSuiteAddTest() routine is used to add a new test case to the specified test suite.<br />
<source lang=c><br />
srTestCaseHandle_t srTestSuiteAddTest(srTestSuiteHandle_t tParent, const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new test case is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of test case. If null, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCaseHandle_t <br />
| Handle of the newly created test case. srTEST_CASE_INVALID indicates failure to create test case.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
void tfsuite_addTest(void)<br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "dynamic test case %d", count);<br />
srTestCaseHandle_t test = srTestSuiteAddTest(srTEST_SUITE_DEFAULT, szName);<br />
srTEST_ADD_COMMENT_WITH_LOCATION(test, "this is a dynamic test case");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addTest)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetName ====<br />
The srTestCaseSetName() routine is used to set set the name of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetName(srTestCaseHandle_t tTestCase, const srCHAR *szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string representing the name of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setName(void)<br />
{<br />
srTestCaseSetName(srTEST_CASE_DEFAULT, "Setting name for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setName)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetDescription ====<br />
The srTestCaseSetDescription() routine is used to set the description of the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseSetDescription(srTestCaseHandle_t tTestCase, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szDescr <br />
| Input <br />
| Pointer to a null-terminated string representing the description of test case. Cannot be null.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setDescription(void)<br />
{<br />
srTestCaseSetDescription(srTEST_CASE_DEFAULT,<br />
"Setting description for default case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setDescription)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseAddComment ====<br />
The srTestCaseAddComment() routine is used to add a comment (aka a log) to be reported with the specified test case.<br />
<source lang=c><br />
srWORD srTestCaseAddComment(srTestCaseHandle_t tTestCase, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_addComment(void)<br />
{<br />
srTestCaseAddComment(srTEST_CASE_DEFAULT,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_addComment)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatus ====<br />
The srTestCaseSetStatus() routine is used to set the result of test case.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input <br />
| The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatus(void)<br />
{<br />
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatus)<br />
#endif<br />
</source><br />
<br />
==== srTestCaseSetStatusEx ====<br />
The srTestCaseSetStatusEx() routine is used to set the result of test case and allow specification of an extendedFailureCode.<br />
<source lang=c><br />
srWORD srTestCaseSetStatus(srTestCaseHandle_t tTestCase, srTestStatus_e eStatus, srDWORD dwDuration, srLONG lExtendedFailureCode)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestCase <br />
| Input<br />
| Handle to a test case. srTEST_CASE_DEFAULT can be used for the default test case.<br />
|-<br />
| eStatus <br />
| Input <br />
| Result of the test. dwDuration Input The duration of the test in clock ticks. Using “0” allows the STRIDE Runtime (Intercept Module) to set the time automatically.<br />
|-<br />
| lExtendedFailureCode <br />
| Input <br />
| The Stride framework uses the extendedFailureCode to capture the numeric results of test method when the test method fails via a numeric (non-void, nonbool) return type.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfcase_setStatusEx(void)<br />
{<br />
srTestCaseSetStatusEx(srTEST_CASE_DEFAULT, srTEST_FAIL, 0, -5);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfcase_setStatusEx)<br />
#endif<br />
</source><br />
<br />
==== srTestSuiteAddAnnotation ====<br />
The srTestSuiteAddAnnotation() routine is used to add a new annotation to the specified test suite.<br />
<source lang=c><br />
srTestAnnotationHandle_t srTestSuiteAddAnnotation(rTestSuiteHandle_t tParent, srTestAnnotationLevel_e eLevel, const srCHAR * szName, const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tParent <br />
| Input<br />
| Handle to the parent test suite to which new annotation is to be added. srTEST_SUITE_DEFAULT can be used for the default test suite.<br />
|-<br />
| eLevel<br />
| Input <br />
| Annotation level. Cannot be empty.<br />
|-<br />
| szName <br />
| Input <br />
| Pointer to a null-terminated string that represents the name of annotation. If null, the default host naming scheme will be used.<br />
|-<br />
| szDescr<br />
| Input <br />
| Pointer to a null-terminated string representing the description of annotation. If null, description will be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotationHandle_t <br />
| HHandle of the newly created annotation. srTEST_ANNOTATION_INVALID indicates failure to create annotation.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuite_addAnnotation(void) <br />
{<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
char szName[25];<br />
sprintf(szName, "annotation %d", count);<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
szName,<br />
"description of annotation");<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuite_addAnnotation)<br />
#endif<br />
</source><br />
<br />
==== srTestAnnotationAddComment ====<br />
The srTestAnnotationAddComment() routine is used to add a comment (aka a log) to be reported with the specified annotation.<br />
<source lang=c><br />
srWORD srTestAnnotationAddComment(srTestAnnotationHandle_t tTestAnnotation, const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|-<br />
| tTestAnnotation<br />
| Input<br />
| Handle to an annotation created using srTestSuiteAddAnnotation.<br />
|-<br />
| szLabel<br />
| Input <br />
| Pointer to a null-terminated string for the label. If null, the default label will be applied.<br />
|-<br />
| szFmtComment <br />
| Input <br />
| Pointer to a null-terminated string, which can be formatted, representing the comment. Cannot be null.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=c><br />
#include <srtest.h><br />
<br />
void tfsuiteAnnotation_addComment(void) <br />
{<br />
srTestAnnotationHandle_t annot = <br />
srTestSuiteAddAnnotation(srTEST_SUITE_DEFAULT,<br />
srTEST_ANNOTATION_LEVEL_ERROR,<br />
“annot”,<br />
“annot description”);<br />
srTestAnnotationAddComment(annot,<br />
srNULL,<br />
"this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_flist(“testfunc”, tfsuiteAnnotation_addComment)<br />
#endif<br />
</source><br />
<br />
=== C++ Test Classes ===<br />
The Runtime Test Services C APIs work equally well from C test functions and C++ test classes. If, however, you are using C++ it might be more convinient for you to derive your C++ test classes from the Runtime Test Services C++ base class, ''srTest''. That way you will have access to a set of simpler to use C++ classes. <br />
<br />
The following C++ classes are provided: <br />
* '''[[#class srTest|class srTest]]''' - base test class<br />
* '''[[#class srTestSuite|class srTestSuite]]''' - represents a test suite<br />
* '''[[#class srTestCase|class srTestCase]]''' - represents a test case<br />
* '''[[#class srTestAnnotation|class srTestAnnotation]]''' - represents a test annotation<br />
<br />
==== class srTest ====<br />
The srTest class provides two Member Objects:<br />
*''testSuite'' of class srTestSuite <br />
*''testCase''of class srTestCase<br />
<br />
==== class srTestSuite ====<br />
The srTest class provides the folowing methods:<br />
<br />
===== method AddSuite =====<br />
The AddSuite method is used to add a new test suite.<br />
<source lang=cpp><br />
srTestSuite AddSuite(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
|szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test suite. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestSuite <br />
| Newly created test suite class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
stride::srTestSuite suite = testSuite.AddSuite("tc Sub Suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test suite.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetName(void);<br />
};<br />
<br />
void srtest_class::suiteSetName(void)<br />
{<br />
testSuite.SetName("Setting name for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test suite.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test suite. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|- <br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteSetDescription(void);<br />
};<br />
<br />
void srtest_class::suiteSetDescription(void)<br />
{<br />
testSuite.SetDescription("Setting description for suite");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddTest =====<br />
The AddTest method is used to add a new test case to test suite.<br />
<source lang=cpp><br />
srTestCase AddTest(const srCHAR * szName = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of test case. If empty, the default host naming scheme will be used.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestCase <br />
| Newly created test case class.<br />
|}<br />
<br><br />
'''Example'''<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddSuite(void);<br />
};<br />
<br />
void srtest_class::suiteAddSuite(void)<br />
{<br />
const std::string prefix("dynamic test case ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strm;<br />
strm << prefix << count;<br />
stride::srTestCase tc = testSuite.AddTest(strm.str().c_str());<br />
tc.AddComment("this is a dynamic test case");<br />
tc.SetStatus(srTEST_PASS);<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddAnnotation =====<br />
The AddAnnotation method is used to add a new annotation to test suite.<br />
<source lang=cpp><br />
srTestAnnoation AddAnnotation(srTestAnnotationLevel_e eLevel, const srCHAR * szName = srNULL, const srCHAR * szDescr = srNULL)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eLevel<br />
| Input<br />
| Annotation level. Cannot be empty.<br />
|- <br />
| szName <br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the name of annotation. If empty, the default host naming scheme will be used.<br />
|- <br />
| szDescr<br />
| Input (Optional)<br />
| Pointer to null-terminated string that represents the description of annotation. If empty, the description will be blank.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srTestAnnotation<br />
| Newly created annotation class.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
#include <sstream><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAddAnnotation(void);<br />
};<br />
<br />
void srtest_class::suiteAddAnnotation(void) <br />
{<br />
const std::string prefixName("annotation ");<br />
const std::string prefixDescr("description of annotation ");<br />
for (int count = 0; count < 5; ++count)<br />
{<br />
std::stringstream strmName;<br />
std::stringstream strmDescr;<br />
strmName << prefixName << count;<br />
strmDescr << prefixDescr << count;<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
strmName.str().c_str(),<br />
strmDescr.str().c_str());<br />
}<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestCase ====<br />
The srTestCase class provides the following methods:<br />
<br />
===== method SetName =====<br />
The SetName method is used to set the name of test case.<br />
<source lang=cpp><br />
srWORD SetName(const srCHAR * szName)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szName <br />
| Input <br />
| Pointer to null-terminated string representing the name of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetName(void);<br />
};<br />
<br />
void srtest_class::caseSetName(void)<br />
{<br />
testCase.SetName("Setting name for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetDescription =====<br />
The SetDescription method is used to set the description of test case.<br />
<source lang=cpp><br />
srWORD SetDescription(const srCHAR * szDescr)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szDescr <br />
| Input <br />
| Pointer to null-terminated string representing the description of test case. Cannot be empty.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetDescription(void);<br />
};<br />
<br />
void srtest_class::caseSetDescription(void)<br />
{<br />
testCase.SetDescription("Setting description for case");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to test case.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseAddComment(void);<br />
};<br />
<br />
void srtest_class::caseAddComment(void)<br />
{<br />
testCase.AddComment("this comment should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
===== method SetStatus =====<br />
The SetStatus method is used to set the result of the default test case.<br />
<source lang=cpp><br />
srWORD SetStatus(srTestStatus_e eStatus, srDWORD dwDuration = 0)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| eStatus <br />
| Input <br />
| Result of the test.<br />
|-<br />
| dwDuration <br />
| Input (Optional)<br />
| The duration of the test in clock ticks. The default is 0.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void caseSetStatus(void);<br />
};<br />
<br />
void srtest_class::caseSetStatus(void)<br />
{<br />
testCase.SetStatus(srTEST_INPROGRESS, 0);<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
==== class srTestAnnotation ====<br />
The srTestAnnotation class provides the following methods:<br />
<br />
===== method AddComment =====<br />
The AddComment method is used to add a comment to an annotation created under a test suite.<br />
<source lang=cpp><br />
srWORD AddComment(const srCHAR * szLabel, const srCHAR * szFmtComment, ...)<br />
</source><br />
<br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;" <br />
| '''Parameters''' <br />
| '''Type'''<br />
| '''Description'''<br />
|- <br />
| szLabel<br />
| Input <br />
| Pointer to null-terminated string for the label. If null, the default label will be applied.<br />
|- <br />
| szFmtComment <br />
| Input <br />
| Pointer to null-terminated string, which can be formatted, representing the comment. Cannot be empty.<br />
|-<br />
| ... <br />
| Input (Optional)<br />
| Variable argument list to format the comment szFmtComment.<br />
|}<br />
<br><br />
{| border="1" cellspacing="0" cellpadding="10" style="align:left;"<br />
| '''Return Value'''<br />
| ''' Description'''<br />
|-<br />
| srOK <br />
| Success<br />
|-<br />
| srERR <br />
| Null string passed in.<br />
|-<br />
| srTEST_ERR_HANDLE_INVALID <br />
| Invalid handle passed in.<br />
|-<br />
| srTEST_WARN_STR_TRUNCATED <br />
| String passed in was too large and was truncated.<br />
|}<br />
<br />
<source lang=cpp><br />
#include <srtest.h><br />
<br />
class srtest_class : public stride::srTest<br />
{<br />
public:<br />
void suiteAnnotationAddComment(void);<br />
};<br />
<br />
void srtest_class::suiteAnnotationAddComment(void)<br />
{<br />
stride::srTestAnnotation ta = <br />
testSuite.AddAnnotation(srTEST_ANNOTATION_LEVEL_INFO,<br />
“annot”,<br />
“annot description”);<br />
ta.AddComment("this comment on annotation should print %s", "A STRING");<br />
}<br />
<br />
#ifdef _SCL<br />
#pragma scl_test_class(srtest_class)<br />
#endif<br />
</source><br />
<br />
Refer to the [[Media:s2sSCLReferenceGuide.pdf|SCL Reference Guide]] or the [[Media:s2sRuntime.pdf|Runtime Developer's Guide]] for detailed information about any of these APIs.<br />
<br />
== ASSERT/EXPECT Macros ==<br />
<br />
The STRIDE Test Unit implementation also provides a set of Test Macros available for use within test methods. The macros are optional - you are not required to use them in your test units. They provide shortcuts for testing assertions and automatic report annotation in the case of failures. <br />
<br />
The macros can currently only be used in C++ test unit code. <br />
<br />
=== General guidelines for all macros ===<br />
<br />
srEXPECT_xx macros will set the current test case to fail (if it hasn’t already been set) and produce an annotation in the report if the expectation fails. If the expectation succeeds, there is no action. <br />
<br />
srASSERT_xx macros will set the current test case to fail (if it hasn’t already been set) and insert an annotation into the report if the assertion fails. In addition, a return from the current function will occur. srASSERT_xx macros can only be used in test functions which return void. If the assertion succeeds there is no action. <br />
<br />
The report annotation produced by a failed macro always includes the source file and line along with details about the condition that failed and the failing values. <br />
<br />
<nowiki>All the macros support the adding to the report annotations using the << operator. For example:</nowiki><br />
<br />
srEXPECT_TRUE( a != <nowiki>b) << “My custom message”; </nowiki><br />
<br />
<nowiki>As delivered, the macros will support stream operator annotations using all the numeric types, char* and s2String. The user may create custom types to be used a report annotation by providing an implementation of the << operator for their custom type. The details are explained in a section below. </nowiki><br />
<br />
=== Boolean Macros ===<br />
The boolean macros take a single condition expression, ''cond'', that evaluates to an integral type or bool. The condition will be evaluated once. if ''cond'' evaluates to non-zero the assertion or expectation fails. When a failure occurs the report will be annotated. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE(''cond'');<br />
| srASSERT_TRUE(''cond'');<br />
| ''cond'' is true<br />
<br />
|-<br />
| srEXPECT_FALSE(''cond'');<br />
| srASSERT_FALSE(''cond'');<br />
| ''cond'' is false<br />
<br />
|}<br />
<br />
=== Comparison Macros ===<br />
<br />
Comparison macros take two operands and compare them using the indicated operator. The comparison macros will work for primitive types as well as objects that have the corresponding comparison operator implemented. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ(''val1'', ''val2'');<br />
| srASSERT_EQ(''val1'', ''val2'');<br />
| ''val1'' == ''val2''<br />
<br />
|-<br />
| srEXPECT_NE(''val1'', ''val2'');<br />
| srASSERT_NE(''val1'', ''val2'');<br />
| ''val1'' != ''val2''<br />
<br />
|-<br />
| srEXPECT_LT(''val1'', ''val2'');<br />
| srASSERT_LT(''val1'', ''val2'');<br />
| ''val1''<nowiki> < </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_LE(''val1'', ''val2'');<br />
| srASSERT_LE(''val1'', ''val2'');<br />
| ''val1''<nowiki> <= </nowiki>''val2''<br />
<br />
|-<br />
| srEXPECT_GT(''val1'', ''val2'');<br />
| srASSERT_GT(''val1'', ''val2'');<br />
| ''val1'' > ''val2''<br />
<br />
|-<br />
| srEXPECT_GE(''val1'', ''val2'');<br />
| srASSERT_GE(''val1'', ''val2'');<br />
| ''val1'' >= ''val2''<br />
<br />
|}<br />
<br />
=== C String Comparison Macros ===<br />
<br />
C String Comparison Macros are intended only for use with C-style zero terminated strings. The strings can be char or wchar_t based. In particular, these macros should not be used for object of one or other string class, since such classes have overloaded comparison operators. The standard comparison macros should be used instead. <br />
<br />
* The length of a string displayed in the report annotation message is controllable via the following macro: srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY (found in srtestmacros.h). If a string value is truncated because of the length limit, the text "...(trunc)" will always appear next to it. <br />
* An empty string will appear in error message output as “”. A null string will appear as NULL with no surrounding quotes. Otherwise all output strings are quoted. <br />
* The type of str1 and str2 must be compatible with const char* or const wchar_t*. <br />
<br />
<br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ(''str1'', ''str2'');<br />
| srASSERT_STREQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content<br />
<br />
|-<br />
| srEXPECT_STRNE(''str1'', ''str2'');<br />
| srASSERT_STRNE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ(''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have the same content, ignoring case.<br />
<br />
|-<br />
| srEXPECT_STRCASENE(''str1'', ''str2'');<br />
| srASSERT_STRCASENE(''str1'', ''str2'');<br />
| ''str1'' and ''str2'' have different content, ignoring case.<br />
<br />
|}<br />
<br />
=== Exception Macros ===<br />
Exception macros are used to ensure that expected exceptions are thrown. They require exception support from the target compiler. If the target compiler does not have exception support the macros cannot be used and must be disabled. The support can be disabled via the macro srCFG_TEST_MACROS_EXCEPTIONS_ON found in srtestmacros.h. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW(statement, ex_type);<br />
| srASSERT_THROW(statement, ex_type);<br />
| ''statement'' throws an exception of type ''ex_type''<br />
<br />
|-<br />
| srEXPECT_THROW_ANY(''statement'');<br />
| srASSERT_THROW_ANY(''statement'');<br />
| ''statement'' throws an exception (type not important)<br />
<br />
|-<br />
| srEXPECT_NO_THROW(''statement'');<br />
| srASSERT_NO_THROW(''statement'');<br />
| ''statement'' does not throw an exception<br />
<br />
|}<br />
<br />
=== Predicate Macros ===<br />
Predicate macros allow user control over the pass/fail decision making in a macro. A predicate is a function returning bool that is implemented by the user but passed to the macro. Other arguments for the predicate are also passed to the macro. The macros allow for predicate functions with up to four parameters. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1(''pred'', ''val1'')<br />
| srASSERT_PRED1(''pred'', ''val1'')<br />
| ''pred''(''val1'') returns true<br />
<br />
|-<br />
| srEXPECT_PRED2(''pred'', ''vall'', ''val2'')<br />
| srASSERT_PRED2(''pred'', ''vall'', ''val2'')<br />
| ''pred''(''val1'', ''val2'') returns true<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
| <br />
<br />
|}<br />
All predicate macros require a predicate function function which returns bool. The predicate macros allow functions with one to 4 parameters. Following are the report annotations resulting from expectation or assertion failures.<br />
<br />
=== Floating Point Macros ===<br />
<br />
Floating point macros are for comparing equivalence (or near equivalence) of floating point numbers. These macros are necessary since because equivalence comparisons for floating point numbers will often fail due to round-off errors. <br />
<br />
{| class="prettytable"<br />
| colspan="3" | '''Floating Point Macros'''<br />
<br />
|-<br />
| srEXPECT_NEAR(val1, val2, epsilon);<br />
| srASSERT_NEAR(val1, val2, epsilon);<br />
| The absolute value of the difference between val1 and va2 is epsilon.<br />
|}<br />
<br />
=== Dynamic Test Case Macros ===<br />
The macros presented so far are not capable of dealing with dynamic test cases. In order to handle dynamic test cases, each of the macros requires another parameter which is the test case to report against. Other than this, these macros provide exactly equivalent functionality to the non-dynamic peer. The dynamic macros are listed below. All require a test case, value of type srTestCaseHandle_t from srtest.h, to be passed as the first parameter).<br />
<br />
{| class="prettytable"<br />
| '''''Nonfatal assertion'''''<br />
| '''''Fatal Assertion'''''<br />
<br />
|-<br />
| colspan="2" | '''Boolean'''<br />
<br />
|-<br />
| srEXPECT_TRUE_DYN(tc, ''cond'');<br />
| srASSERT_TRUE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| srEXPECT_FALSE_DYN(tc, ''cond'');<br />
| srASSERT_FALSE_DYN(tc, ''cond'');<br />
<br />
|-<br />
| colspan="2" | '''Comparison'''<br />
<br />
|-<br />
| srEXPECT_EQ_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_EQ_DYN(tc, ''expect'', ''val'');<br />
<br />
|-<br />
| srEXPECT_NE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_NE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_LE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_LE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GT_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GT_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| srEXPECT_GE_DYN(tc, ''val1'', ''val2'');<br />
| srASSERT_GE_DYN(tc, ''val1'', ''val2'');<br />
<br />
|-<br />
| colspan="2" | '''C-string comparison'''<br />
<br />
|-<br />
| srEXPECT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STREQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRNE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASEEQ_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| srEXPECT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
| srASSERT_STRCASENE_DYN(tc, ''str1'', ''str2'');<br />
<br />
|-<br />
| colspan="2" | '''Exceptions'''<br />
<br />
|-<br />
| srEXPECT_THROW_DYN(statement, ex_type);<br />
| srASSERT_THROW_DYN(tc, statement, ex_type);<br />
<br />
|-<br />
| srEXPECT_THROW_ANY_DYN(tc, ''statement'');<br />
| srASSERT_THROW_ANY_DYN(tc, ''statement'');<br />
<br />
|-<br />
| srEXPECT_NO_THROW_DYN(tc, ''statement'');<br />
| srASSERT_NO_THROW_DYN(tc, ''statement'');<br />
<br />
|-<br />
| colspan="2" | '''Predicates'''<br />
<br />
|-<br />
| srEXPECT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
| srASSERT_PRED1_DYN(tc, ''pred'', ''val1'');<br />
<br />
|-<br />
| srEXPECT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
| srASSERT_PRED2_DYN(tc, ''pred'', ''vall'', ''val2'');<br />
<br />
|-<br />
| …(up to arity of 4)<br />
| <br />
<br />
|-<br />
| colspan="2" | '''Floating Point'''<br />
<br />
|-<br />
| srEXPECT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
| srASSERT_NEAR_DYN(tc, ''val1'', ''val2'', ''epsilon'');<br />
<br />
|}<br />
<br />
=== Overloading The << operator for report annotation ===<br />
<nowiki>The user of the asserting macros package may overload the << operator in order to annotate reports using a custom class. An example is below. </nowiki><br />
<br />
<nowiki>The following will compile and execute successfully given that the << operator is overloaded as shown:</nowiki><br />
<br />
<pre><br />
MyCustomClass custom(34); <br />
<br />
srEXPECT_FALSE(true) << custom;<br />
<br />
// MyCustomClass implementation<br />
class MyCustomClass<br />
{<br />
public:<br />
MyCustomClass(int i) : m_int(i) {}<br />
<br />
private: <br />
int m_int; <br />
friend stride::Message& operator<< <br />
( stride::Message& ss, const MyCustomClass& obj);<br />
}; <br />
<br />
stride::Message& operator<<(stride::Message& ss, const MyCustomClass& obj)<br />
{<br />
<br />
// format the internals as a string and send on<br />
char buf[20]; <br />
sprintf(buf, "%d", obj.m_int); <br />
ss << buf;<br />
return ss;<br />
}<br />
</pre><br />
<br />
=== Test Macro Configuration ===<br />
<br />
The Test Macros are implemented in C++. Because target support for use of the standard libraries and exceptions varies across targets the macro implementation can be configured. <br />
<br />
==== Configuring Test Macros When Exceptions Not Available ====<br />
If the target compiler does not support exceptions (or they are disabled) the Exception Macros must be disabled. This is accomplished by setting srCFG_TEST_MACROS_EXCEPTIONS_ON to 0 in the file srtestmacros.h.<br />
<br />
==== Configuring Test Macros When C++ Standard Library is Not Available ====<br />
If the C++ standard library can be used within the target code, the test macro implementation uses std::string and std::stringstream. If the classes are not available on the target, then an alternate, custom implementation that relies only on C library support can be used. <br />
<br />
The choice is configured via srCFG_TEST_MACROS_USE_STANDARD_LIB found within srtestmacros.h<br />
<br />
==== Configuring Report Annotation for C-String Comparisons ====<br />
<br />
The C-String comparison macros are used to compare strings. When comparisons fail, the values involved in the failed comparison are normally displayed in the report. If the strings are very long, this is probably not desirable. It is possible to constrain the maximum length of the displayed strings using srCFG_TEST_MACROS_MAX_C_STRING_MESSAGE_DISPLAY. String values longer than this value will be truncated in report annotations. <br />
<br />
<br />
== Scripting a Test Unit ==<br />
<br />
To automate the execution and reporting of a Test Unit a script is required. Scripts can be written by hand or automatically generated using the Script Wizard and a corresponding template script. A scripting tool for executing a test unit is the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection. An [[AutoScript#ascript.TestUnits.Item|Ascript TestUnit]] object assembles all of the reporting information for the test unit and its corresponding test methods. <br />
<br />
*Require useage of the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection <br />
*Can be written by hand (refer below) <br />
*Can leverage [[Templates|Templates]] via the Script Wizard <br />
*Order of multiple test units dictated by SUID assignment<br />
<br />
<br> <br />
<br />
=== JScript example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=javascript><br />
// Ensure test unit exists<br />
if (ascript.TestUnits.Item("Simple") != null) <br />
ascript.TestUnits.Item("Simple").Run();<br />
</source><br />
<br />
=== Perl example for a single test unit ===<br />
<br />
The following example script is used to harness a test unit that has been captured using #pragma scl_test_class(Simple). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
my $tu = $main::ascript->TestUnits->Item("Simple");<br />
if (defined $tu) {<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
=== JScript example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=javascript><br />
var Units = ["Simple1","Simple2"];<br />
<br />
// iterate through each function<br />
for (i in Units)<br />
{<br />
var tu = ascript.TestUnits.Item(Units[i]);<br />
if ( tu&nbsp;!= null ) <br />
tu.Run();<br />
}<br />
</source><br />
<br />
=== Perl example for multiple test units ===<br />
<br />
The following example script is used to harness two test units that have been captured using #pragma scl_test_class(Simple1) and #pragma scl_test_class(Simple2). <br />
<br />
<source lang=perl><br />
use strict;<br />
use Win32::OLE;<br />
Win32::OLE->Option(Warn => 3);<br />
<br />
# initialize an array with all selected function names<br />
my @UnitNames = ("Simple1","Simple2");<br />
foreach (@UnitNames) { <br />
my $tu = $main::ascript->TestUnits->Item($_->[1]);<br />
die "TestUnit not found: $_->[1]\n" unless (defined $tu);<br />
$tu->Run();<br />
}<br />
</source><br />
<br />
[[Category:Test Units]]<br />
[[Category:Reference]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Main_Page&diff=8759Main Page2009-01-05T19:46:42Z<p>Jaimeg: </p>
<hr />
<div>Welcome to the S2 Technologies™ '''STRIDE'''™''' 3.0 Support Wiki'''. <br />
<br />
All contributions are welcome and encouraged. Please read '''[[Help:How to add a topic|How to add a topic]]''' and '''[[Help:Contents|Help]]''' pages for guidelines and instructions on editing. You must '''[[Special:Userlogin|log in or create an account]]''' before you can edit a page. <br />
<br />
Please select a topic or category heading below, or enter a search string in the Search field to the left. <br />
<br />
----<br />
<br />
<br><br />
<br />
{| class="FCK__ShowTableBorders"<br />
|-<br />
| <br />
|}<br />
<br />
{| class="FCK__ShowTableBorders"<br />
|-<br />
| valign="top" | <br />
{| class="FCK__ShowTableBorders" style="border-right: rgb(187,204,204) 1px solid; border-top: rgb(187,204,204) 1px solid; vertical-align: top; border-left: rgb(187,204,204) 1px solid; border-bottom: rgb(187,204,204) 1px solid" cellspacing="5" cellpadding="2"<br />
|-<br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Installation|Installation]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Reference|Reference]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Samples|Samples]] <!--<br />
Deploying<br />
--><br />
|-<br />
| valign="top" | <br />
*[[Desktop_Installation|Desktop Installation]] <br />
*[[Build_Integration|Build Integration]] <br />
*[[Target_Integration|Target Integration]] <br />
*[[Verifying Installation|Verification]]<u></u><br />
<br />
<!--<br />
Reference<br />
--><br />
<br />
| valign="top" | <br />
<ul><br />
<li>[[Reference Overview|Overview]]</li><br />
<li>[[Runtime Reference|Runtime]]</li> <br />
<li>[[Build Tools|Build Tools]]</li> <br />
<li>[[SCL_Pragmas|SCL Pragmas]]</li> <br />
<li>[[Intercept Module|Intercept Module]]</li> <br />
<li>[[AutoScript|AutoScript]]</li> <br />
<li>[[Reporter|Reporter]]</li> <br />
<li>[[STRIDE_Studio|Studio]]</li> <br />
<li><categorytree mode=pages depth=0>SDKs</categorytree></li><br />
<li><categorytree mode=pages depth=0>Utilities</categorytree></li><br />
</ul><br />
<br />
<!--<br />
Samples<br />
--><br />
<br />
| valign="top" | <br />
*[[Samples Overview]]<br />
*[[Install_Test_Sample|Install Test]]<br />
*[[Hello_Stride_Sample|Hello Stride]]<br />
*[[Test_Unit_Samples|Test Units]]<br />
*[[Test_Script_Samples|Test Scripts]] <br />
*[[SCL_Samples|SCL]]<br />
*[[Intercept_Module_Sample|Intercept Module]]<br />
<br />
|-<br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Practice|Practice]] <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Application Notes|Notes]] <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Release Notes|Release Notes]]<br />
|-<br />
| valign="top" | <br />
<ul> <br />
<li><categorytree mode="all" depth=0>Documentation</categorytree></li> <br />
<li><categorytree mode="all" depth=0>Script Writing</categorytree></li> <br />
<li><categorytree mode="all" depth=0>Project Organization</categorytree></li> <br />
</ul><br />
<br />
<!--<br />
Notes<br />
--><br />
<br />
| valign="top" | <br />
<categorytree mode="all" hideroot="on">Application Notes</categorytree> <!--<br />
Release Notes<br />
--><br />
<br />
| valign="top" | <br />
*[[STRIDE 2.1.00xx|STRIDE 2.1.00xx (D Street)]] <br />
*[[STRIDE 3.0.01xx|STRIDE 3.0.01xx (StoneSteps)]]<br />
<br />
|}<br />
<br />
|}</div>Jaimeghttps://www.stridewiki.com/index.php?title=Studio:Intercept_Module_Sample&diff=8638Studio:Intercept Module Sample2008-12-13T01:42:44Z<p>Jaimeg: /* Settings */</p>
<hr />
<div>==Introduction==<br />
<br />
The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\InterceptModule''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Intercept Module|Intercept Module (IM)]] source code, and a STRIDE workspace for doing more advanced test execution.<br />
<br />
==Prerequisites==<br />
The following prerequisites must be satisfied (see [[Desktop Installation]] for more info) before starting:<br />
* STRIDE must be installed on the Windows PC to be used in the training, and any required licenses must be present.<br />
* Active State Perl must be installed, and [[Desktop Installation#Perl|additional perl packages]] must be downloaded and installed. '''Note:''' when the sample workspace is executed, a script runs that verifies that the required Perl packages have been installed correctly.<br />
* Microsoft Visual Studio 2005 or a later version must be installed. If you do not currently have any version of Visual Studio, we recommend that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary.<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom [[Build_Tools|STRIDE build]] rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the sample source code.<br />
<br />
Once the build is complete you can open the STRIDE workspace file and run all scripts using the [[image:Run_all.gif]] button. When run, a simple test report will be produced with a single Passed test and no failures. Although this example produces a report, the focus of it is on the source code instrumentation and intercept module settings, both of which are most easily viewed in the Visual Studio workspace. The STRIDE workspace provides a means to execute some function call sequences to demonstrate that the call routing via the STRIDE runtime indeed works.<br />
<br />
==Sample Tests==<br />
<br />
Now that you have built the Windows Off-Target App and executed the tests it contains, you can take time to peruse the Visual Studio project source and settings. This section provides a brief description for the topics covered by this sample workspace. This project is organized in folders, as described in the following sections. The section names match the project folder being described.<br />
<br />
===Main===<br />
<br />
Contains the application entry point and the generated Intercept Module source file.<br />
<br />
===Settings===<br />
<br />
Contains a text file with the Intercept options that are used by the project. This file is passed to the [[s2sinstrument]] tool as part of the [[Windows_Off-Target_SDK#Instructions_for_Microsoft_Visual_Studio|STRIDE build rules]]. we have chosen to name this file ''stride.s2sinstrument'' to make clear that it applies the s2sinstrument tool, but the name is not required by the tools (any basename and suffix are allowed).<br />
<br />
===Source=== <br />
<br />
Contains the application code that we have instrumented so as to illustrate the IM concepts outlined below. The following sub-folders present several IM related concepts. For each of these samples, refer to the ''stride.s2sinstrument'' settings file to see the corresponding tool settings that are required to properly generate the IM code.<br />
<br />
====Stub====<br />
<br />
Illustrates creation of a [[Intercept Module#Stub|Stub Intercept Module (IM)]], which is required to be included in the target build to call a function on the target platform from the host.<br />
<br />
====Proxy====<br />
<br />
Demonstrates creation of a [[Intercept Module#Proxy|Proxy Intercept Module (IM)]], which is required to be included in the target build to call a function on the host platform from a function on the target. <br />
<br />
====Delegate User Implicit====<br />
<br />
Illustrates creation of a [[Intercept Module#Delegate|Delegate User Implicit Intercept Module (IM)]], which is required to be included in the target build to trace on a user (calling) function with implicit [[Name Mangling|name mangling]] that resides wholly on the target.<br />
<br />
====Delegate User Explicit====<br />
<br />
Illustrates creation of a [[Intercept Module#Delegate|Delegate User Explicit Intercept Module (IM)]], which is required to be included in the target build to trace on a user (calling) function with explicit [[Name Mangling|name mangling]] that resides wholly on the target.<br />
<br />
====Delegate Owner Implicit====<br />
<br />
Illustrates creation of a [[Intercept Module#Delegate|Delegate Owner Implicit Intercept Module (IM)]], which is required to be included in the target build to trace on a owner (called) function with implicit [[Name Mangling|name mangling]] that resides wholly on the target.<br />
<br />
====Delegate Owner Explicit====<br />
<br />
Illustrates creation of a [[Intercept Module#Delegate|Delegate Owner Explicit Intercept Module (IM)]], which is required to be included in the target build to trace on a owner (called) function with [[Name Mangling|name mangling]] that resides wholly on the target.<br />
<br />
====Delegate Dynamic====<br />
<br />
Illustrates creation of a [[Intercept Module#Delegate|Delegate Dynamic Intercept Module (IM)]], which is required to be included in the target build to transparently route calls to either a target-based or host-based implementation of a function.<br />
<br />
==Workspace Execution==<br />
<br />
The sample STRIDE workspace contains a few basic scripts that drive the execution of the interfaces in the sample application. The workspace is of little interest other than verifying that the interfaces can be called and invoke the proper proxies and delegates.<br />
<br />
<br />
<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_CClass_Sample&diff=8634Test CClass Sample2008-12-12T23:01:46Z<p>Jaimeg: </p>
<hr />
<div>== Introduction ==<br />
The Test CClass Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The CClass naming convention implies a C struct that is acting like a class object for the purpose of test unit development. The Test CClass Samples pertain to implementing test units in the C language that appear to act like test classes. If you are using C++, you will want to use the [[Test_Class_Sample|Test Class Samples]] for simplicity. The Test CClass functionality is predominantly for legacy systems that have not switched over to C++. However, the Test CClass functionality is not restricted from compiling C++ environment as well.<br />
<br><br><br />
The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestCClass''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|scl_test_cclass]] source code, and a STRIDE workspace for doing more advanced test CClass execution.<br />
<br />
== Getting Started ==<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version installed, you should be able to open this solution (it will be automatically upgraded if necessary). If you do not have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated. The rebuilding will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test CClasss in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestCClass.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory (%STRIDE_DIR%\Samples\TestUnits\TestCClass).<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestCClass.exe application by typing 'q' in its console window.<br />
<br />
== Sample Test CClass Examples ==<br />
Now that you have built the Windows Off-Target App and executed the test CClass it contains, you can take time to peruse the test CClass source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
=== Basic Examples ===<br />
These examples cover the simplest, easiest way to code a STRIDE test CClass. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
==== 01_01_Basic_Simple ====<br />
This example demonstrates passing and failing tests using the four primary POD types that infer status from (int, short, and char). The bool type is accepted only in C++ mode.<br />
<br />
==== 01_02_Basic_Fixtures ====<br />
This example demonstrates how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
==== 01_03_Basic_Constructors ====<br />
This example demonstrates how scl_test_cclass may be used with parameterized constructors. These arguments can be passed using our ascript scripting model for test units.<br />
<br />
=== Runtime Services Examples ===<br />
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).<br />
<br />
==== 02_01_RuntimeServices_Simple ====<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.<br />
<br />
==== 02_02_RuntimeServices_Dynamic ====<br />
This example demonstrates how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test case, and annotation creation in the context of a single test method.<br />
<br />
==== 02_03_RuntimeServices_Override ====<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
==== 02_04_RuntimeServices_VarComment ====<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
== Test CClass Execution ==<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
=== Commandline Execution ===<br />
Command line execution for test CClasss is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun]] utility. Here are several examples with specific syntax to execute scl_test_cclass tests. All of these commands can be invoked from a standard command shell and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestCClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
==== Simple execution of all test units ====<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is included for completeness.<br />
<br />
TestUnitRun.pl -d TestCClass.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test CClass initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see the following:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Constructors...<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 16<br />
Failed: 7<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 8 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on an order file ====<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the scl_test_cclass tests in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestCClass.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 8<br />
Failed: 4<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 4 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on file system order ====<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your test CClass source files (only the files that contain the scl_test_CClass pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test CClass source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestCClass.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Constructors...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 16<br />
Failed: 7<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 10 suites.<br />
***************************************************************************<br />
<br />
=== Workspace-based Execution ===<br />
TestCClass.ssw, a workspace in the TestCClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provided basic infrastructure scripts that start/stop the simulator application (TestCClass.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
==== RunAll ====<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
====CallConstructor====<br />
<br />
This folder contains a simple script example that shows how to invoke test classes with constructor arguments. In this example, the Basic_Constructors test class is executed twice with different initialization (constructor) arguments both times.<br />
<br />
==== Run Individual ====<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CClass_NAME''').Run();<br />
<br />
The '''TEST_CClass_NAME''' is the name of the scl_test_cclass test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_cclass tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_CClass_Sample&diff=8633Test CClass Sample2008-12-12T22:49:46Z<p>Jaimeg: </p>
<hr />
<div>== Introduction ==<br />
The Test CClass Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The CClass naming convention implies a C struct that is acting like a class object for the purpose of test unit development. The Test CClass Samples pertain to implementing test units in the C language that appear to act like test classes. If you are using C++, you will want to use the [[Test_Class_Sample|Test Class Samples]] for simplicity. The Test CClass functionality is predominantly for legacy systems that have not switched over to C++. However, the Test CClass functionality is not restricted from compiling C++ environment as well.<br />
<br><br><br />
The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestCClass''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|scl_test_cclass]] source code, and a STRIDE workspace for doing more advanced test CClass execution.<br />
<br />
== Getting Started ==<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version installed, you should be able to open this solution (it will be automatically upgraded if necessary). If you do not have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated. The rebuilding will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test CClasss in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestCClass.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory (%STRIDE_DIR%\Samples\TestUnits\TestCClass).<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestCClass.exe application by typing 'q' in its console window.<br />
<br />
== Sample Test CClass Examples ==<br />
Now that you have built the Windows Off-Target App and executed the test CClass it contains, you can take time to peruse the test CClass source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
=== Basic Examples ===<br />
These examples cover the simplest, easiest way to code a STRIDE test CClass. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
==== 01_01_Basic_Simple ====<br />
This example demonstrates passing and failing tests using the four primary POD types that infer status from (int, short, and char). The bool type is accepted only in C++ mode.<br />
<br />
==== 01_02_Basic_Fixtures ====<br />
This example demonstrates how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
==== 01_03_Basic_Constructors ====<br />
This example demonstrates how scl_test_cclass may be used with parameterized constructors. These arguments can be passed using our ascript scripting model for test units.<br />
<br />
=== Runtime Services Examples ===<br />
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).<br />
<br />
==== 02_01_RuntimeServices_Simple ====<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.<br />
<br />
==== 02_02_RuntimeServices_Dynamic ====<br />
This example demonstrates how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test case, and annotation creation in the context of a single test method.<br />
<br />
==== 02_03_RuntimeServices_Override ====<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
==== 02_04_RuntimeServices_VarComment ====<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
== Test CClass Execution ==<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
=== Commandline Execution ===<br />
Command line execution for test CClasss is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun]] utility. Here are several examples with specific syntax to execute scl_test_cclass tests. All of these commands can be invoked from a standard command shell and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestCClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
==== Simple execution of all test units ====<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is included for completeness.<br />
<br />
TestUnitRun.pl -d TestCClass.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test CClass initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see the following:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Constructors...<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 16<br />
Failed: 7<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 8 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on an order file ====<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the scl_test_cclass tests in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestCClass.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 8<br />
Failed: 4<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 4 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on file system order ====<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your test CClass source files (only the files that contain the scl_test_CClass pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test CClass source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestCClass.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Constructors...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestCClass\TestCClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 16<br />
Failed: 7<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 10 suites.<br />
***************************************************************************<br />
<br />
=== Workspace-based Execution ===<br />
TestCClass.ssw, a workspace in the TestCClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provided basic infrastructure scripts that start/stop the simulator application (TestCClass.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
==== RunAll ====<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
==== Run Individual ====<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CClass_NAME''').Run();<br />
<br />
The '''TEST_CClass_NAME''' is the name of the scl_test_cclass test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_cclass tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Class_Sample&diff=8630Test Class Sample2008-12-12T21:05:21Z<p>Jaimeg: </p>
<hr />
<div>==Introduction==<br />
The Test Class Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestClass''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|test class]] source code, and a STRIDE workspace for doing more advanced test class execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestClass.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestClass.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Classes==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test class source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' each of the example test classes is grouped in namespace corresponding to its top-level category (e.g. ''Basic'' or ''Runtime Services''). This is something shown for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover the simplest, easiest way to code a STRIDE test class. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
====01_01_Basic_Simple====<br />
<br />
This example demonstrates passing and failing tests using the four primary POD types that infer status from (int, bool, short, and char).<br />
<br />
====01_02_Basic_Fixtures====<br />
<br />
This example demonstrates how to use [[Test_Units#Pragmas_for_Test_Units|setup and teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
====01_03_Basic_Exceptions====<br />
<br />
This example demonstrates how exceptions thrown from a test method are caught by the intercept module and noted in the results. Any exception that is caught by the harness is assumed to indicate failure.<br />
<br />
====01_04_Basic_Constructors====<br />
<br />
This example demonstrates how test classes may have non-trivial constructors. These arguments can be passed using the [[AutoScript#ascript.TestUnits|ascript]] scripting model for test units.<br />
<br />
===Runtime Services Examples===<br />
<br />
These examples cover basic usage of the Runtime Test Services API (as declared in srtest.h).<br />
<br />
====02_01_RuntimeServices_Simple====<br />
<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information. <br />
<br />
====02_02_RuntimeServices_Dynamic====<br />
<br />
This example demonstrates how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.<br />
<br />
====02_03_RuntimeServices_Override====<br />
<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
====02_04_RuntimeServices_VarComment====<br />
<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
===srTest Examples===<br />
<br />
These examples show to how to use the [[Test_Units#C.2B.2B_Test_Classes|stride::srTest]] base class for your test classes. When you publicly inherit from srTest, you get access to default testCase and testSuite members and their associated methods.<br />
<br />
====03_01_srTest_Simple====<br />
<br />
This example demonstrates the use of [[Test_Units#SetStatus|testCase.setStatus]] to set the status for test cases.<br />
<br />
====03_02_srTest_Dynamic====<br />
<br />
This example demonstrates how to use [[Test_Units#AddSuite|testSuite.AddSuite]], [[Test_Units#AddTest|testSuite.AddTest]], [[Test_Units#AddAnnotation|testSuite.AddAnnotation]], and [[Test_Units#AddAnnotation.AddComment|testSuite.AddAnnotation.AddComment]] for dynamic suite, test case, and annotation creation within the context of one test method.<br />
<br />
==Test Class Execution==<br />
<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test classes is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test classes. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestClass.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Class initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Constructors...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::Fixtures...<br />
Running Test Basic::Simple...<br />
Running Test RuntimeServices::Dynamic...<br />
Running Test RuntimeServices::Override... <br />
Running Test RuntimeServices::Simple...<br />
Running Test RuntimeServices::VarComment...<br />
Running Test srTest::Dynamic...<br />
Running Test srTest::Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 26<br />
Failed: 12<br />
In Progress: 2<br />
Not Applicable: 2<br />
...in 12 suites.<br />
***************************************************************************<br />
<br />
====Execution based on an order file====<br />
<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the Test Classes in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestClass.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Simple...<br />
Running Test RuntimeServices::Simple...<br />
Running Test srTest::Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 6<br />
In Progress: 2<br />
Not Applicable: 2<br />
...in 6 suites.<br />
***************************************************************************<br />
<br />
====Execution based on filesystem order====<br />
<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your test class source files (only the files that contain the scl_test_class pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test class source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestClass.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Simple...<br />
Running Test Basic::Fixtures...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::Constructors...<br />
Running Test RuntimeServices::Simple...<br />
Running Test RuntimeServices::Dynamic...<br />
Running Test RuntimeServices::Override...<br />
Running Test RuntimeServices::VarComment...<br />
Running Test srTest::Simple...<br />
Running Test srTest::Dynamic...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 26<br />
Failed: 12<br />
In Progress: 2<br />
Not Applicable: 2<br />
...in 15 suites.<br />
***************************************************************************<br />
<br />
===Workspace-based Execution===<br />
<br />
TestClass.ssw, a workspace in the TestClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestClass.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
====CallConstructor====<br />
<br />
This folder contains a simple script example that shows how to invoke test classes with constructor arguments. In this example, the Basic::Constructors test class is executed twice with different initialization (constructor) arguments both times.<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_Class_NAME''' is the name of the scl_test_class test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_class tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Class_Sample&diff=8629Test Class Sample2008-12-12T21:02:13Z<p>Jaimeg: </p>
<hr />
<div>==Introduction==<br />
The Test Class Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestClass''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|test class]] source code, and a STRIDE workspace for doing more advanced test class execution.<br />
<br />
==Getting Started==<br />
<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version of Visual Studio installed, you should be able to open this solution and it will be automatically upgraded if necessary. If you do not currently have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated and will produce a STRIDE database, intercept module source files, and a Windows Off-Target App that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test classes in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestClass.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestClass.exe application by typing 'q' in its console window.<br />
<br />
==Sample Test Classes==<br />
<br />
Now that you have built the Windows Off-Target App and executed the test classes it contains, you can take time to peruse the test class source and the corresponding results that each produces. This section provides a brief description for each.<br />
<br />
''NOTE:'' each of the example test classes is grouped in namespace corresponding to its top-level category (e.g. ''Basic'' or ''Runtime Services''). This is something shown for organizational purposes only -- it is '''not''' a general requirement that test classes be placed into namespaces. <br />
<br />
===Basic Examples===<br />
<br />
These examples cover the simplest, easiest way to code a STRIDE test class. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
====01_01_Basic_Simple====<br />
<br />
This example demonstrates passing and failing tests using the four primary POD types that infer status from (int, bool, short, and char).<br />
<br />
====01_02_Basic_Fixtures====<br />
<br />
This example demonstrates how to use [[Test_Units#Pragmas_for_Test_Units|setup and teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
====01_03_Basic_Exceptions====<br />
<br />
This example demonstrates how exceptions thrown from a test method are caught by the intercept module and noted in the results. Any exception that is caught by the harness is assumed to indicate failure.<br />
<br />
====01_04_Basic_Constructors====<br />
<br />
This example demonstrates how test classes may have non-trivial constructors. These arguments can be passed using the [[AutoScript#ascript.TestUnits|ascript]] scripting model for test units.<br />
<br />
===Runtime Services Examples===<br />
<br />
These examples cover basic usage of the Runtime Test Services API (as declared in srtest.h).<br />
<br />
====02_01_RuntimeServices_Simple====<br />
<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information. <br />
<br />
====02_02_RuntimeServices_Dynamic====<br />
<br />
This example demonstrates how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.<br />
<br />
====02_03_RuntimeServices_Override====<br />
<br />
This example demonstrates how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
====02_04_RuntimeServices_VarComment====<br />
<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
===srTest Examples===<br />
<br />
These examples show to how to use the [[Test_Units#C.2B.2B_Test_Classes|stride::srTest]] base class for your test classes. When you publicly inherit from srTest, you get access to default testCase and testSuite members and their associated methods.<br />
<br />
====03_01_srTest_Simple====<br />
<br />
This example demonstrates the use of [[Test_Units#SetStatus|testCase.setStatus]] to set the status for test cases.<br />
<br />
====03_02_srTest_Dynamic====<br />
<br />
This example demonstrates how to use [[Test_Units#AddSuite|testSuite.AddSuite]], [[Test_Units#AddTest|testSuite.AddTest]], [[Test_Units#AddAnnotation|testSuite.AddAnnotation]], and [[Test_Units#AddAnnotation.AddComment|testSuite.AddAnnotation.AddComment]] for dynamic suite, test case, and annotation creation within the context of one test method.<br />
<br />
==Test Class Execution==<br />
<br />
This sample demonstrates two different techniques for executing test classes.<br />
<br />
===Command Line Execution===<br />
<br />
Command line execution for test classes is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun utility]]. Here are several examples of specific syntax to execute test classes. All of these commands can be invoked from a standard [http://en.wikipedia.org/wiki/Command_Prompt_(Windows) command shell] (or other shell of your choosing) and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestClass.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
====Simple execution of all test units====<br />
<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestClass.sidb<br />
<br />
This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Class initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see console output like:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Constructors...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::Fixtures...<br />
Running Test Basic::Simple...<br />
Running Test RuntimeServices::Dynamic...<br />
Running Test RuntimeServices::Override... <br />
Running Test RuntimeServices::Simple...<br />
Running Test RuntimeServices::VarComment...<br />
Running Test srTest::Dynamic...<br />
Running Test srTest::Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 26<br />
Failed: 12<br />
In Progress: 2<br />
Not Applicable: 2<br />
...in 12 suites.<br />
***************************************************************************<br />
<br />
====Execution based on an order file====<br />
<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the Test Classes in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestClass.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Simple...<br />
Running Test RuntimeServices::Simple...<br />
Running Test srTest::Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 13<br />
Failed: 6<br />
In Progress: 2<br />
Not Applicable: 2<br />
...in 6 suites.<br />
***************************************************************************<br />
<br />
====Execution based on filesystem order====<br />
<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your test class source files (only the files that contain the scl_test_class pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test class source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestClass.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic::Simple...<br />
Running Test Basic::Fixtures...<br />
Running Test Basic::Exceptions...<br />
Running Test Basic::Constructors...<br />
Running Test RuntimeServices::Simple...<br />
Running Test RuntimeServices::Dynamic...<br />
Running Test RuntimeServices::Override...<br />
Running Test RuntimeServices::VarComment...<br />
Running Test srTest::Simple...<br />
Running Test srTest::Dynamic...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestClass\TestClass.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 28<br />
Failed: 12<br />
In Progress: 2<br />
Not Applicable: 2<br />
...in 15 suites.<br />
***************************************************************************<br />
<br />
===Workspace-based Execution===<br />
<br />
TestClass.ssw, a workspace in the TestClass directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provide basic infrastructure scripts that start/stop the simulator application (TestClass.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
====RunAll====<br />
<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
====CallConstructor====<br />
<br />
This folder contains a simple script example that shows how to invoke test classes with constructor arguments. In this example, the Basic::Constructors test class is executed twice with different initialization (constructor) arguments both times.<br />
<br />
====Run Individual====<br />
<br />
This folder shows how to use individual scripts to execute test classes. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_CLASS_NAME''').Run();<br />
<br />
The '''TEST_Class_NAME''' is the name of the scl_test_class test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_class tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Function_List_Sample&diff=8626Test Function List Sample2008-12-12T17:57:40Z<p>Jaimeg: </p>
<hr />
<div>== Introduction ==<br />
The Test Function List Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. Function Lists are abbreviated as 'FList' in both pragmas (as in scl_test_flist) and documentation. The Test FList Samples pertain to test units that contain lists of functions to be executed. The Test FList functionality is designed to be used for the C language (although it is not restricted from compilation in a C++ environment as well). <br />
<br><br><br />
The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestFList''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|scl_test_flist]] source code, and a STRIDE workspace for doing more advanced test function list execution.<br />
<br />
== Getting Started ==<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version installed, you should be able to open this solution (it will be automatically upgraded if necessary). If you do not have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated, The rebuilding will produce a STRIDE database, intercept module source files, and a [[Windows_Off-Target_Apps|Windows Off-Target App]] that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test flists in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestFList.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestFList.exe application by typing 'q' in its console window.<br />
<br />
== Sample Test FLists ==<br />
Now that you have built the Windows Off-Target App and executed the test flists it contains, you can take time to peruse the test flist source within the STRIDE Studio Project. This section provides a brief description for each. The names of the sections align with the names of the project folders within the STRIDE Studio Project. <br />
<br />
=== Basic Examples ===<br />
These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
==== 01_01_Basic_Simple ====<br />
This example demonstrates passing and failing tests using the primary POD types that infer status from (int, bool, short, and char). The bool type is only accepted in C++ mode.<br />
<br />
==== 01_02_Basic_Fixtures ====<br />
This example shows how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
=== Runtime Services Examples ===<br />
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).<br />
<br />
==== 02_01_RuntimeServices_Simple ====<br />
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.<br />
<br />
==== 02_02_RuntimeServices_Dynamic ====<br />
This example shows how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.<br />
<br />
==== 02_03_RuntimeServices_Override ====<br />
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
==== 02_04_RuntimeServices_VarComment ====<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
== Test FList Execution ==<br />
This sample demonstrates two different techniques for executing scl_test_flist code.<br />
<br />
=== Commandline Execution ===<br />
Command line execution for TestFlist is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun]] utility. Here are several examples of specific syntax to execute function lists. All of these commands can be invoked from a standard command shell and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestFList.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
==== Simple execution of all test units ====<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestFList.sidb<br />
<br />
This command executes all Test Units found in the (TestFList.sidb) database in descending alpha-numeric sort order. Any Test FList initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see the following:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 16<br />
Failed: 6<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on an order file ====<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the function list tests in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestFList.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)(debug)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 8<br />
Failed: 4<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 4 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on file system order ====<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your function list test source files (only the files that contain the scl_test_flist pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test flist source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestFList.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test Basic_Fixtures...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 16<br />
Failed: 6<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
=== Workspace-based Execution ===<br />
TestFList.ssw, a workspace in the TestFList directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provided basic infrastructure scripts that start/stop the simulator application (TestFList.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
==== RunAll ====<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
==== Run Individual ====<br />
This folder shows how to use individual scripts to execute scl_test_flist tests. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_FList_NAME''').Run();<br />
<br />
The '''TEST_FList_NAME''' is the name of the scl_test_flist test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_flist tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Function_List_Sample&diff=8625Test Function List Sample2008-12-12T17:56:13Z<p>Jaimeg: </p>
<hr />
<div>== Introduction ==<br />
The Test Function List Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. Function Lists are abbreviated as 'FList' in both pragmas (as in scl_test_flist) and documentation. The Test FList Samples pertain to test units that contain lists of functions to be executed. The Test FList functionality is designed to be used for the C language (although it is not restricted from compilation in a C++ environment as well). <br />
<br><br><br />
The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestFList''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|scl_test_flist]] source code, and a STRIDE workspace for doing more advanced test function list execution.<br />
<br />
== Getting Started ==<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version installed, you should be able to open this solution (it will be automatically upgraded if necessary). If you do not have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated, The rebuilding will produce a STRIDE database, intercept module source files, and a [[Windows_Off-Target_Apps|Windows Off-Target App]] that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test flists in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestFList.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestFList.exe application by typing 'q' in its console window.<br />
<br />
== Sample Test FLists ==<br />
Now that you have built the Windows Off-Target App and executed the test flists it contains, you can take time to peruse the test flist source within the STRIDE Studio Project. This section provides a brief description for each. The names of the sections align with the names of the project folders within the STRIDE Studio Project. <br />
<br />
=== Basic Examples ===<br />
These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
==== 01_01_Basic_Simple ====<br />
This example demonstrates passing and failing tests using the primary POD types that infer status from (int, bool, short, and char). The bool type is only accepted in C++ mode.<br />
<br />
==== 01_02_Basic_Fixtures ====<br />
This example shows how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
=== Runtime Services Examples ===<br />
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).<br />
<br />
==== 02_01_RuntimeServices_Simple ====<br />
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.<br />
<br />
==== 02_02_RuntimeServices_Dynamic ====<br />
This example shows how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.<br />
<br />
==== 02_03_RuntimeServices_Override ====<br />
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
==== 02_04_RuntimeServices_VarComment ====<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
== Test FList Execution ==<br />
This sample demonstrates two different techniques for executing scl_test_flist code.<br />
<br />
=== Commandline Execution ===<br />
Command line execution for TestFlist is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun]] utility. Here are several examples of specific syntax to execute function lists. All of these commands can be invoked from a standard command shell and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestFList.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
==== Simple execution of all test units ====<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestFList.sidb<br />
<br />
This command executes all Test Units found in the (TestFList.sidb) database in descending alpha-numeric sort order. Any Test FList initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see the following:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 17<br />
Failed: 6<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on an order file ====<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the function list tests in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestFList.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)(debug)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 8<br />
Failed: 4<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 4 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on file system order ====<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your function list test source files (only the files that contain the scl_test_flist pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test flist source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestFList.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test Basic_Fixtures...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 17<br />
Failed: 6<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
=== Workspace-based Execution ===<br />
TestFList.ssw, a workspace in the TestFList directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provided basic infrastructure scripts that start/stop the simulator application (TestFList.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
==== RunAll ====<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
==== Run Individual ====<br />
This folder shows how to use individual scripts to execute scl_test_flist tests. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_FList_NAME''').Run();<br />
<br />
The '''TEST_FList_NAME''' is the name of the scl_test_flist test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_flist tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Test_Function_List_Sample&diff=8624Test Function List Sample2008-12-12T17:48:31Z<p>Jaimeg: </p>
<hr />
<div>== Introduction ==<br />
The Test Function List Samples are part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]]. Function Lists are abbreviated as 'FList' in both pragmas (as in scl_test_flist) and documentation. The Test FList Samples pertain to test units that contain lists of functions to be executed. The Test FList functionality is designed to be used for the C language (although it is not restricted from compilation in a C++ environment as well). <br />
<br><br><br />
The following content relates to the sample files and workspaces installed in ''%STRIDE_DIR%\Samples\TestUnits\TestFList''. This sample consists of a [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio] workspace for building a [[Windows_Off-Target_Apps|Windows Off-Target App]], sample [[Test Units|scl_test_flist]] source code, and a STRIDE workspace for doing more advanced test function list execution.<br />
<br />
== Getting Started ==<br />
To begin, open the Visual Studio Solution file in the sample directory. This solution (and corresponding project) were created for Visual Studio 2005. If you have a later version installed, you should be able to open this solution (it will be automatically upgraded if necessary). If you do not have any version of Visual Studio, it is recommended that you install the current free version of [http://en.wikipedia.org/wiki/Visual_Studio_Express Visual Studio Express].<br />
<br />
Once you have successfully opened the solution, rebuild it. The build process has custom STRIDE build rules integrated, The rebuilding will produce a STRIDE database, intercept module source files, and a [[Windows_Off-Target_Apps|Windows Off-Target App]] that incorporates the test class source.<br />
<br />
Once the build is complete, perform the following steps to run the test flists in the workspace:<br />
<br />
# launch the Windows Off-Target App, TestFList.exe. This will run in a standard console window.<br />
# open a command prompt window and change to this sample's directory.<br />
# at the command prompt, run the command <tt>'''TestUnitRun.pl -v'''</tt>. This will execute all of the test units in the workspace and open a browser to display the results.<br />
# quit the TestFList.exe application by typing 'q' in its console window.<br />
<br />
== Sample Test FLists ==<br />
Now that you have built the Windows Off-Target App and executed the test flists it contains, you can take time to peruse the test flist source within the STRIDE Studio Project. This section provides a brief description for each. The names of the sections align with the names of the project folders within the STRIDE Studio Project. <br />
<br />
=== Basic Examples ===<br />
These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments).<br />
<br />
==== 01_01_Basic_Simple ====<br />
This example demonstrates passing and failing tests using the primary POD types that infer status from (int, bool, short, and char). The bool type is only accepted in C++ mode.<br />
<br />
==== 01_02_Basic_Fixtures ====<br />
This example shows how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.<br />
<br />
=== Runtime Services Examples ===<br />
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).<br />
<br />
==== 02_01_RuntimeServices_Simple ====<br />
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.<br />
<br />
==== 02_02_RuntimeServices_Dynamic ====<br />
This example shows how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddTest|srTestSuiteAddTest]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.<br />
<br />
==== 02_03_RuntimeServices_Override ====<br />
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value.<br />
<br />
==== 02_04_RuntimeServices_VarComment ====<br />
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]].<br />
<br />
== Test FList Execution ==<br />
This sample demonstrates two different techniques for executing scl_test_flist code.<br />
<br />
=== Commandline Execution ===<br />
Command line execution for TestFlist is done using the [[Test_Runners#TestUnitRun.pl|TestUnitRun]] utility. Here are several examples of specific syntax to execute function lists. All of these commands can be invoked from a standard command shell and the arguments shown assume that the commands are executed with the sample's directory as the starting directory. You must have your TestFList.exe application running in order for the runner to be able to initiate a connection to the target simulator. In addition, you should verify that your %STRIDE_DIR%\bin\transport.cfg file is using the TCP transport to connect to port 8000 (these are the default settings when the product is installed).<br />
<br />
==== Simple execution of all test units ====<br />
The following command executes all of the test units found in the STRIDE database you have previously generated. For the purpose of this sample, since there is only one database, the -d parameter is not strictly needed, but it is shown here for completeness.<br />
<br />
TestUnitRun.pl -d TestFList.sidb<br />
<br />
This command executes all Test Units found in the (TestFList.sidb) database in descending alpha-numeric sort order. Any Test FList initialization arguments are given default values (typically zero or NULL).<br />
<br />
When you run this command, you should see the following:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Fixtures...<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 17<br />
Failed: 6<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 7 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on an order file ====<br />
TestUnitRun can optionally base its execution on simple text file input. A simple order file, ''RunSimple.txt'', is provided which specifies a subset of all the function list tests in this sample. This order file also shows how to create subsuites in the final output by using the special '''{suitepath}''' syntax, as described in [[Test_Runners#Usage|the usage section]].<br />
<br />
TestUnitRun.pl -d TestFList.sidb -o RunSimple.txt<br />
<br />
...and will produce this output:<br />
<br />
Attempting connection using [Sockets (S2)(debug)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test RuntimeServices_Simple...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 8<br />
Failed: 4<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 4 suites.<br />
***************************************************************************<br />
<br />
==== Execution based on file system order ====<br />
TestUnitRun can also try to infer execution order and suite hierarchy from filesystem organization. If you have organized your function list test source files (only the files that contain the scl_test_flist pragma matter here) in a filesystem hierarchy that you want to mimic in your tests, you can specify a root of a directory tree that contains the relevant test flist source. TestUnitRun will walk the directory structure and determine order and hierarchy of tests based on the directory structure. To see an example of this in action, you can execute this command with the sample:<br />
<br />
TestUnitRun.pl -d TestFList.sidb -f Tests<br />
<br />
This will cause the runner to examine the Tests subdirectory structure and build a hierarchy of tests based on that directory tree. Subdirectories will map to suites in the final report. Here is the output for this example:<br />
<br />
Attempting connection using [Sockets (S2)] transport ...<br />
Connected to device.<br />
Initializing STRIDE database objects...<br />
Done.<br />
Running Test Basic_Simple...<br />
Running Test Basic_Fixtures...<br />
Running Test RuntimeServices_Simple...<br />
Running Test RuntimeServices_Dynamic...<br />
Running Test RuntimeServices_Override...<br />
Running Test RuntimeServices_VarComment...<br />
Disconnected from device.<br />
Test Results saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.xml<br />
Test Report saved to C:\STRIDE\Samples\TestUnits\TestFList\TestFList.html<br />
***************************************************************************<br />
Results Summary<br />
***************************************************************************<br />
Passed: 17<br />
Failed: 6<br />
In Progress: 1<br />
Not Applicable: 1<br />
...in 9 suites.<br />
***************************************************************************<br />
<br />
=== Workspace-based Execution ===<br />
TestFList.ssw, a workspace in the TestFList directory, demonstrates the use of script execution with Studio to manage test order and hierarchy. This workspace was created using [[WorkspaceSetup.pl]]. The setup and teardown folders provided basic infrastructure scripts that start/stop the simulator application (TestFList.exe) and to manage traceviews used for [[Runtime_Reference#Logging_Services|srPrint]] message collection. The scripts that drive the testing are in the workspace '''test''' folder. What follows is a brief description for each.<br />
<br />
==== RunAll ====<br />
This folder contains a script, All.js, that iterates through the entire collection of test units and executes them one at a time. The order of execution will be in ascending alpabetical order (by name) since the [[AutoScript#ascript.TestUnits|ArrangeBy]] collection method was called.<br />
<br />
==== Run Individual ====<br />
This folder shows how to use individual scripts to execute scl_test_flist tests. Each script has the following form:<br />
<br />
ascript.TestUnits.Item('''TEST_FList_NAME''').Run();<br />
<br />
The '''TEST_FList_NAME''' is the name of the scl_test_flist test to be run. The order and hierarchy of each item may be changed via the Studio tree control by moving the item within the scripts and/or folders. The sample contains individual scripts for a few of the sample scl_test_flist tests - you are free to move, add, or delete any items as you experiment with the workspace.<br />
<br />
[[Category: Samples]]</div>Jaimeghttps://www.stridewiki.com/index.php?title=Main_Page&diff=8419Main Page2008-12-04T21:35:17Z<p>Jaimeg: </p>
<hr />
<div>Welcome to the S2 Technologies™ '''STRIDE'''™''' 3.0 Support Wiki'''. <br />
<br />
All contributions are welcome and encouraged. Please read '''[[Help:How to add a topic|How to add a topic]]''' and '''[[Help:Contents|Help]]''' pages for guidelines and instructions on editing. You must '''[[Special:Userlogin|log in or create an account]]''' before you can edit a page. <br />
<br />
Please select a topic or category heading below, or enter a search string in the Search field to the left. <br />
<br />
----<br />
<br />
<br><br />
<br />
{| class="FCK__ShowTableBorders"<br />
|-<br />
| <br />
|}<br />
<br />
{| class="FCK__ShowTableBorders"<br />
|-<br />
| valign="top" | <br />
{| class="FCK__ShowTableBorders" style="border-right: rgb(187,204,204) 1px solid; border-top: rgb(187,204,204) 1px solid; vertical-align: top; border-left: rgb(187,204,204) 1px solid; border-bottom: rgb(187,204,204) 1px solid" cellspacing="5" cellpadding="2"<br />
|-<br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Installation|Installation]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Reference|Reference]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Samples|Samples]] <!--<br />
Deploying<br />
--><br />
|-<br />
| valign="top" | <br />
*[[Host_Installation|Host Installation]] <br />
*[[Build_Integration|Build Integration]] <br />
*[[Target_Integration|Target Integration]] <br />
*[[Verifying Installation|Verification]]<u></u><br />
<br />
<!--<br />
Reference<br />
--><br />
<br />
| valign="top" | <br />
<ul><br />
<li>[[Reference Overview|Overview]]</li><br />
<li>[[Runtime Reference|Runtime]]</li> <br />
<li>[[Build Tools|Build Tools]]</li> <br />
<li>[[SCL_Pragmas|SCL Pragmas]]</li> <br />
<li>[[Intercept Module|Intercept Module]]</li> <br />
<li>[[AutoScript|AutoScript]]</li> <br />
<li>[[Reporter|Reporter]]</li> <br />
<li>[[STRIDE_Studio|Studio]]</li> <br />
<li><categorytree mode=pages depth=0>SDKs</categorytree></li><br />
<li><categorytree mode=pages depth=0>Utilities</categorytree></li><br />
</ul><br />
<br />
<!--<br />
Samples<br />
--><br />
<br />
| valign="top" | <br />
*[[Hello_Stride_Sample|Hello Stride]]<br />
*[[Test_Unit_Samples|Test Units]]<br />
*[[Test_Script_Samples|Test Scripts]] <br />
*[[SCL_Samples|SCL]]<br />
*[[Intercept_Module_Sample|Intercept Module]]<br />
*[[Install_Test_Sample|Install Test]]<br />
<br />
|-<br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Practice|Practice]] <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Application Notes|Notes]] <br />
! style="border-right: rgb(163,176,191) 1px solid; padding-right: 0.4em; border-top: rgb(163,176,191) 1px solid; padding-left: 0.4em; font-weight: bold; font-size: 120%; background: rgb(206,223,242) 0% 50%; padding-bottom: 0.2em; margin: 0pt; border-left: rgb(163,176,191) 1px solid; color: rgb(0,0,0); padding-top: 0.2em; border-bottom: rgb(163,176,191) 1px solid; text-align: left; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial" | [[:Category:Release Notes|Release Notes]]<br />
|-<br />
| valign="top" | <br />
<ul> <br />
<li><categorytree mode="all" depth=0>Documentation</categorytree></li> <br />
<li><categorytree mode="all" depth=0>Script Writing</categorytree></li> <br />
<li><categorytree mode="all" depth=0>Project Organization</categorytree></li> <br />
</ul><br />
<br />
<!--<br />
Notes<br />
--><br />
<br />
| valign="top" | <br />
<categorytree mode="all" hideroot="on">Application Notes</categorytree> <!--<br />
Release Notes<br />
--><br />
<br />
| valign="top" | <br />
*[[STRIDE 2.1.00xx|STRIDE 2.1.00xx (D Street)]] <br />
*[[STRIDE 3.0.01xx|STRIDE 3.0.01xx (StoneSteps)]]<br />
<br />
|}<br />
<br />
|}</div>Jaimeghttps://www.stridewiki.com/index.php?title=STRIDE_Build_Tools&diff=8191STRIDE Build Tools2008-10-31T22:10:29Z<p>Jaimeg: fixed minor typo on Partial Intercept Module</p>
<hr />
<div>__FORCETOC__<br />
<br />
=Build Tools=<br />
The STRIDE Build Tools are a set of command line utilities that perform the Stride compile/build process on a supported platform, which may be easily invoked through makefiles or similar build utilities (eg. ANT).<br />
<br />
==Command Line Utilities==<br />
# [[s2scompile|The STRIDE Compiler (s2scompile)]]<br><br><br />
# [[s2sbind|The STRIDE Database Binder (s2sbind)]]<br><br><br />
# [[s2sinstrument|The STRIDE Instrumentation Generator (s2sinstrument)]]<br />
''Follow the above links for detailed information on each build tool.''<br />
<br />
==Examples==<br />
<br />
===Compiling multiple files===<br />
In this scenario, the '''s2scompile''' utility is invoked with a list of header files, containing SCL, each to be compiled a resulting intermediate (.meta) file:<br />
<br />
s2scompile –I"C:\STRIDE\inc" –DN=100 file1.h file2.h<br />
<br />
===Database Binding===<br />
Here, the '''s2sbind''' utility is invoked with a list of .meta files to be bound into the specified database (.sidb) file:<br />
<br />
s2sbind –-starting_suid=123 test.sidb file1.h.meta file2.h.meta<br />
<br />
===Intercept Module Generation===<br />
====Single Intercept Module====<br />
=====Pre-build Instrumentation=====<br />
In this scenario, the compilation, binding and instrumentation are done before the user’s build. Here, '''s2scompile''' is called first, then '''s2sbind''', and finally '''s2sinstrument''':<br />
<br />
s2scompile –I”C:\STRIDE\inc” –DN=100 file1.h file2.h<br />
s2sbind –-starting_suid=123 test.sidb file1.h.meta file2.h.meta<br />
s2sinstrument –-im_name=test -–mode=SDud#myGroupID(f1) -–mode=P(f2) test.sidb<br />
<br />
=====In-build Prototyping with Post-build Implementation=====<br />
Here, the compilation, binding and Intercept Module(IM) prototyping (header files only generation) are done incrementally. Note that at the second bind step during prototyping, '''s2sbind''' is given an option specifying the existing database to merge with. Also note that '''s2sinstrument''' is called the first two times with the "prototype" option specified and then finally is called with the "implement" option for code generation:<br />
<br />
s2scompile –I”C:\STRIDE\inc” –DN=100 file1.h<br />
s2sbind –-starting_suid=123 test.sidb file1.h.meta<br />
s2sinstrument –-im_name=test –prototype=p1 -–mode=SDud#myGroupID(f10,f11) test.sidb<br />
<br />
s2scompile –I”C:\STRIDE\inc” –DN=100 file2.h<br />
s2sbind –-input_database=test.sidb test.sidb file2.h.meta<br />
s2sinstrument –-im_name=test –prototype=p2 -–mode=P(f20,f21) test.sidb<br />
<br />
s2sinstrument –-im_name=test –implement -–mode=SDud#myGroupID(f10,f11) -–mode=P(f20,f21) test.sidb<br />
<br />
====Multiple Intercept Modules====<br />
The compilation, binding and Intercept Module(IM) generation (headers and source) are done incrementally. For each component of the user’s build just a subset of SCL files are compiled, bound to a database (merged into the previously created database) and an IM generated for a set of interfaces defined in those SCL files.<br />
This example shows how this can be accomplished. Notice that a unique name is specified for each IM when s2sinstrument is called:<br />
<br />
s2scompile –I”C:\STRIDE\inc” –DN=100 file1.h<br />
s2sbind –-starting_suid=123 test.sidb file1.h.meta<br />
s2sinstrument –-im_name=test1 -–mode=SDud#myGroupID(f1) test.sidb<br />
<br />
s2scompile –I”C:\STRIDE\inc” –DN=100 file2.h<br />
s2sbind –-input_database=test.sidb test.sidb file2.h.meta<br />
s2sinstrument –-im_name=test2 -–mode=P(f2) test.sidb<br />
<br />
====Partial Intercept Module====<br />
<br />
By default, the instrumentation of a referenced database generates IM code for all functions. If no '''--mode''' option is specified the generate IM code would be all Stub.<br />
<br />
s2sinstrument test.sidb<br />
<br />
The user can control that default behavior by passing explicitly '''--default_mode''' option. For example to generate Proxy for all functions except for function f3:<br />
<br />
s2sinstrument --default_mode=P --mode=(f3) test.sidb<br />
<br />
In certain cases it might be desirable to generate partial intercept module - IM code for only specific set of functions. That requires disabling the default behaviour and listing the requested functions with '''--mode''' option. For example to generate Stub|Delegate|User|Dynamic IM code for only functions f1 and f2:<br />
<br />
s2sinstrument --default_mode=# --mode=SDud#myGroupID(f1,f2) test.sidb<br />
<br />
<br />
[[Category: Reference]]<br />
[[Category: Build Tools]]</div>Jaimeg