|
|
| (261 intermediate revisions by 8 users not shown) |
| Line 1: |
Line 1: |
| − | ==Introduction== | + | == What are STRIDE Test Units? == |
| | | | |
| − | STRIDE enables testing of C++ code through the use of xUnit-style test classes. Test classes 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 classes by automatically creating entry points for the execution of test classes on the target. | + | '''STRIDE Test Units''' is a general term for [http://en.wikipedia.org/wiki/XUnit xUnit-style] test modules running within the STRIDE runtime framework. These tests--written in C and C++--are compiled and linked with your embedded software and run in-place on your target hardware. They are suitable for both developer unit testing as well as end-to-end integration testing. |
| | | | |
| − | ==Using C++ test classes==
| + | An external [[Stride Runner|Test Runner]] is provided which controls the execution of the tests and publishes test results to the local file system and optionally to S2's Internet [[STRIDE Test Space]]. |
| | | | |
| − | ===Prerequisites=== | + | == Test Unit Features == |
| | + | In all cases, STRIDE Test Units provide the following capabilities typical of all [http://en.wikipedia.org/wiki/XUnit xUnit-style] testing frameworks: |
| | + | * Specification of a test as a test method |
| | + | * Aggregation of individual tests into test suites which form execution and reporting units |
| | + | * Specification of expected results within test methods (typically by using one or more [[Test Code Macros]]) |
| | + | * Test fixturing (optional setup and teardown) |
| | + | * Test parametrization (optional constructor/initialization parameters) |
| | + | * Automated execution |
| | + | * Automated results report generation |
| | | | |
| − | see [[Installing STRIDE#Third Party Components| Perl requirements]].
| + | === Unique STRIDE Test Unit Features === |
| | + | In addition, STRIDE Test Units offer these unique features: |
| | + | ; On-Target Execution |
| | + | : Tests execute on the target hardware in a true operational environment. Execution and reporting is controlled from a remote desktop (Windows, Linux or FreeBSD) host |
| | + | ; Dynamic Test and Suite Generation |
| | + | : Test cases and suites can be created and manipulated at runtime |
| | + | ; [[Using Test Doubles|Test Doubles]] |
| | + | : Dynamic runtime function substitution to implement on-the-fly mocks, stubs, and doubles |
| | + | ; [[Test Point Testing in C/C++|Behavior Testing]] (Test Points) |
| | + | : Support for testing of asynchronous activities occurring in multiple threads |
| | + | ; Multiprocess Testing Framework |
| | + | : Support for testing across multiple processes running simultaneously on the target |
| | + | ; Automatic Timing Data Collection |
| | + | : Duration are automatically measured for each test case. |
| | + | ; Automatic Results Publishing to Local Disk and Internet |
| | + | : Automatic publishing of test results to [[STRIDE Test Space]] |
| | | | |
| − | ===How to get started(Overview)===
| + | [[Category:Test Units]] |
| − | | |
| − | The required steps to get started with writing C++ test classes are as follows:
| |
| − | | |
| − | <ol>
| |
| − | <li>Create a new Studio workspace (or open an existing one).</li>
| |
| − | <li>Set the workspace to compile in C++ mode (In Studio, choose Tools->Settings->Compile as Cpp).</li>
| |
| − | <li>Add '''%STRIDE_DIR%'''\inc\srtest.h to the Source Files folder of your workspace.</li>
| |
| − | <li>Create a script to compile the workspace.</li>
| |
| − | <li>Create a script to generate the Intercept Module(IM) '''after''' the compilation step.
| |
| − | :For the simple STUB generation required for C++ test class execution, you can use the following code (perl syntax)</li>
| |
| − | <pre>
| |
| − | use strict;
| |
| − | use Win32::OLE qw(in);
| |
| − | Win32::OLE->Option(Warn => 3);
| |
| − | my $intercept = $main::studio->Workspace->Intercept;
| |
| − | $intercept->{Path} = $main::studio->Workspace->Path;
| |
| − | $intercept->{Name} = $main::studio->Workspace->Name;
| |
| − | map {$intercept->Item($_)->{Stub} = 1} (0..($intercept->Count - 1));
| |
| − | $intercept->Create();
| |
| − | </pre>
| |
| − | <li>Add scripts to build and execute your application. If you are using a host-based simulator, examples of both are available from S2. If you are using actual devices, the steps required for building and starting the application are specific to the target environment.</li>
| |
| − | <li>Create one or more test classes to implement your C++ test logic. Click '''[[Test_Classes#C.2B.2B_test_class_requirements|here]]''' for more information on creating test classes.</li>
| |
| − | <li>Ensure that the Studio workspace include path contains the location to all of your test class declaration (header) files.</li>
| |
| − | <li>Once you have created one or more test classes, save and compile the workspace.</li>
| |
| − | <li>If your application is running, you can start executing test classes.
| |
| − | :* You can test-execute individual test classes interactively using the '''Studio interface''' view. To do this, open the user interface view corresponding to the test class 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.
| |
| − | :* Once you are confident that the test classes are behaving as expected, you can generate one or more execution scripts using the '''Script Wizard'''. Sample '''[[templates]]''' for executing test class entry points are provided in the %STRIDE_DIR%\templates\Script Wizard directory.
| |
| − | :* There are several installed '''library components''' that provide some of the core functionality for test class harnessing and execution. These components are installed and registered with the core product installation. For sample examples, see the '''[[STRIDE.testclass|Test Class Component]]''' that can be used for running test classes from scripts.</li>
| |
| − | <li>For integration with larger regression test workspaces, we recommend that developers check in their test class code and, optionally, the template-generated scripts that can be used to execute their test classes.</li>
| |
| − | </ol>
| |
| − | | |
| − | ===Pragmas for test classes===
| |
| − | STRIDE supports three pragmas for capturing and qualifying test classes:
| |
| − | | |
| − | * '''<code>scl_test_class ( class )</code>''': Declares a test class as captured. Once captured, STRIDE will generate the appropriate code for executing the test methods in the class.
| |
| − | * '''<code>scl_test_setup ( class , method )</code>''': [optional] Declares a member method to be a setup fixture for the class. If specified, the setup method will be called before the execution of each test method.
| |
| − | * '''<code>scl_test_teardown ( class , method )</code>''': [optional] Declares a member method to be a teardown fixture for the class. If specified, the teardown method will be called after the execution of each test method.
| |
| − | | |
| − | ==C++ test class requirements==
| |
| − | | |
| − | Several variations on typical xUnit-style test classes are supported. The additional supported features include:
| |
| − | * Test status can be set using STRIDE Runtime APIs ''or'' by specifying simple return types for test methods.
| |
| − | * Simple return types: 0 = PASS; <> 0 = FAIL
| |
| − | * void return type with no explict status setting is assumed PASS
| |
| − | * Test writers can create additional child suites and tests at runtime by using Runtime APIs.
| |
| − | * We do not rely on exceptions for reporting of status.
| |
| − | | |
| − | The STRIDE test class framework has the following requirements of each test class:
| |
| − | * The test class must have a suitable default (no-argument) constructor.
| |
| − | * 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.
| |
| − | * the scl_test_class pragma must be applied to the class.
| |
| − | | |
| − | ===Simple example using return values for status===
| |
| − | | |
| − | #include <srtest.h>
| |
| − |
| |
| − | class Simple {
| |
| − | public:
| |
| − | int tc_Int_ExpectPass(void) {return 0;}
| |
| − | int tc_Int_ExpectFail(void) {return -1;}
| |
| − | bool tc_Bool_ExpectPass(void) {return true;}
| |
| − | bool tc_Bool_ExpectFail(void) {return false;}
| |
| − | };
| |
| − | #ifdef _SCL
| |
| − | #pragma scl_test_class(Simple)
| |
| − | #endif
| |
| − | | |
| − | ===Simple example using runtime test service APIs===
| |
| − | | |
| − | #include <srtest.h>
| |
| − |
| |
| − | class RuntimeServices_basic {
| |
| − | public:
| |
| − | void tc_ExpectPass(void)
| |
| − | {
| |
| − | srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");
| |
| − | srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0);
| |
| − | }
| |
| − | void tc_ExpectFail(void)
| |
| − | {
| |
| − | srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");
| |
| − | srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0);
| |
| − | }
| |
| − | void tc_ExpectInProgress(void)
| |
| − | {
| |
| − | srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");
| |
| − | }
| |
| − | };
| |
| − | #ifdef _SCL
| |
| − | #pragma scl_test_class(RuntimeServices_basic)
| |
| − | #endif
| |
| − | | |
| − | ===Simple example using srTest base class===
| |
| − | | |
| − | #include <srtest.h>
| |
| − |
| |
| − | class MyTest : public stride::srTest {
| |
| − | public:
| |
| − | void tc_ExpectPass(void)
| |
| − | {
| |
| − | testCase.AddComment("this test should pass");
| |
| − | testCase.SetStatus(srTEST_PASS, 0);
| |
| − | }
| |
| − | void tc_ExpectFail(void)
| |
| − | {
| |
| − | testCase.AddComment("this test should fail");
| |
| − | testCase.SetStatus(srTEST_FAIL, 0);
| |
| − | }
| |
| − | void tc_ExpectInProgress(void)
| |
| − | {
| |
| − | testCase.AddComment("this test should be in progress");
| |
| − | }
| |
| − | int tc_ChangeMyName(void)
| |
| − | {
| |
| − | testCase.AddComment("this test should have name = MyChangedName");
| |
| − | testCase.SetName("MyChangedName");
| |
| − | return 0;
| |
| − | }
| |
| − | int tc_ChangeMyDescription(void)
| |
| − | {
| |
| − | testCase.AddComment("this test should have a description set");
| |
| − | testCase.SetDescription("this is my new description");
| |
| − | return 0;
| |
| − | }
| |
| − | };
| |
| − | #ifdef _SCL
| |
| − | #pragma scl_test_class(MyTest)
| |
| − | #endif
| |
| − | | |
| − | ==Runtime Test Services==
| |
| − | | |
| − | 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.
| |
| − | | |
| − | The following C APIs are provided:
| |
| − | | |
| − | * '''<code>srTestSuiteAddSuite</code>''': creates an additional sub-suite at runtime.
| |
| − | * '''<code>srTestSuiteSetName</code>''': sets the name of the specified suite.
| |
| − | * '''<code>srTestSuiteSetDescription</code>''': sets the description of the specified suite.
| |
| − | * '''<code>srTestSuiteAddTest</code>''': creates an additional test case at runtime.
| |
| − | * '''<code>srTestCaseSetName</code>''': sets the name of the specified test case.
| |
| − | * '''<code>srTestCaseSetDescription</code>''': sets the description of the specified test case.
| |
| − | * '''<code>srTestCaseAddComment</code>''': adds a comment to the specified test case.
| |
| − | * '''<code>srTestCaseSetStatus</code>''': explicitly sets the status for the specified test case.
| |
| − | | |
| − | These C APIs work equally well from C test functions and C++ test classes. If, however, you choose to derive your C++ test classes from the STRIDE Runtime base class, ''srTest'', then you will have access to member objects in srTest and their methods that provide the same functionality as the C API. The srTest base class provides two Member Objects, via which you can access functionality:
| |
| − | | |
| − | '''''Member Objects''''':
| |
| − | * ''testSuite'', which has methods:
| |
| − | ** '''<code>AddSuite</code>'''
| |
| − | ** '''<code>SetName</code>'''
| |
| − | ** '''<code>SetDescription</code>'''
| |
| − | ** '''<code>AddTest</code>'''
| |
| − | * ''testCase'', which has methods:
| |
| − | ** '''<code>SetName</code>'''
| |
| − | ** '''<code>SetDescription</code>'''
| |
| − | ** '''<code>AddComment</code>'''
| |
| − | ** '''<code>SetStatus</code>'''
| |
| − | | |
| − | Refer to the Reference Guide or the Runtime Developers Guide, both available in the STRIDE Online Help, for detailed information about any of these functions.
| |
| − | | |
| − | ==Scripting a Test Class(Work in progress)==
| |
| − | * Test Class names have "_run" suffix added
| |
| − | * Require useage of Components
| |
| − | * Can be written by hand (refer below)
| |
| − | * Can leverage templates via Script Wizard
| |
| − | | |
| − | | |
| − | === JScript example for a single test class===
| |
| − | | |
| − | // create and initialize the runner object
| |
| − | var runnerClass = new ActiveXObject("STRIDE.testclass");
| |
| − | runnerClass.ascript = ascript;
| |
| − | runnerClass.parentSuite = testSuite;
| |
| − | if (ascript.Functions.Item("Simple_run") != null )
| |
| − | runnerClass.run("Simple_run");
| |
| − |
| |
| − | === Perl example for a single test class===
| |
| − | | |
| − | === JScript example for multiple test classes===
| |
| − | | |
| − | === Perl example for multiple test classes===
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | [[Category:Test Utilities]] | |
