Training Fixturing: Difference between revisions
(Created page with '= Objectives = This Training Module focuses on '''Fixturing''' in the context of the STRIDE Test System. For a high-level overview refer to the following wiki section on [[What_…') |
No edit summary |
||
Line 7: | Line 7: | ||
There are two test files used -- '''TestFixture.cpp & TestFixture.h''' | There are two test files used -- '''TestFixture.cpp & TestFixture.h'''. These implement one Test Unit: | ||
* '''TestFixture''' | * '''TestFixture''' | ||
The Test Unit has one test case already implemented (used for reference) and has '''two test methods''' that you are required to implement (called '''Exercise1''' and '''Exercise2'''). Currently the ''Exercise1'' method is empty | The Test Unit has one test case already implemented (used for reference) and has '''two test methods''' that you are required to implement (called '''Exercise1''' and '''Exercise2'''). Currently the ''Exercise1'' method is empty and returns a ''NOT IN USE'' status. The ''Exercise2'' method does not yet exist. | ||
= Instructions = | = Instructions = | ||
Line 19: | Line 19: | ||
* Build TestApp using SDK makefile | * Build TestApp using SDK makefile | ||
* Startup TestApp | * Startup TestApp | ||
* | * If not already done, create an [[Stride_Runner#Options | option file]] (myoptions.txt) using the following content (Windows example) | ||
##### Command Line Options ###### | ##### Command Line Options ###### | ||
Line 47: | Line 47: | ||
* '''TestFixture::Exercise1''' | * '''TestFixture::Exercise1''' | ||
** Add a ''NOTE'' | ** Add a ''NOTE''that will display the ''name'' of the test | ||
** Validate that '''Sequence2''' is persisted when starting the Thread | ** Validate that '''Sequence2''' is persisted when starting the Thread | ||
Line 53: | Line 53: | ||
** Add new test method declaration called ''Exercise2'' to TestFixture.h | ** Add new test method declaration called ''Exercise2'' to TestFixture.h | ||
** Add new test method implementation of ''Exercise2'' to TestFixture.cpp | ** Add new test method implementation of ''Exercise2'' to TestFixture.cpp | ||
** Add a ''NOTE'' | ** Add a ''NOTE'' that will display the name of the test | ||
** Validate that '''Sequence3''' is persisted when starting the Thread | ** Validate that '''Sequence3''' is persisted when starting the Thread | ||
Line 74: | Line 74: | ||
== Run and Publish Results == | == Run and Publish Results == | ||
When you have completed the Exercise(s) publish your results to Test Space. To make it easier for now we recommend that you update your existing option file (myoptions.txt) with the following: | When you have completed the Exercise(s) publish your results to Test Space. To make it easier for now we recommend that you update your existing option file (myoptions.txt) with the following if not already done: | ||
#### Test Space options (partial) ##### | #### Test Space options (partial) ##### |
Revision as of 23:24, 26 August 2011
Objectives
This Training Module focuses on Fixturing in the context of the STRIDE Test System. For a high-level overview refer to the following wiki section on fixturing. This module focuses on the following topics:
- Startup logic at the beginning of a Test Unit
- Setup logic for each test method
- Teardown logic for each test method
There are two test files used -- TestFixture.cpp & TestFixture.h. These implement one Test Unit:
- TestFixture
The Test Unit has one test case already implemented (used for reference) and has two test methods that you are required to implement (called Exercise1 and Exercise2). Currently the Exercise1 method is empty and returns a NOT IN USE status. The Exercise2 method does not yet exist.
Instructions
Build and Run TestApp
- Build TestApp using SDK makefile
- Startup TestApp
- If not already done, create an option file (myoptions.txt) using the following content (Windows example)
##### Command Line Options ###### --device "TCP:localhost:8000" --database %STRIDE_DIR%\SDK\Windows\out\TestApp.sidb --output %STRIDE_DIR%\SDK\Windows\sample_src\TestApp.xml --log_level all
- Execute Test Fixture Test Unit only
> stride -O myoptions.txt --run TestFixture
Loading database... Connecting to device... Executing... test unit "TestFixture" > 1 passed, 0 failed, 0 in progress, 1 not in use. -------------------------------------------------------------- Summary: 1 passed, 0 failed, 0 in progress, 1 not in use. Disconnecting from device... Saving result file...
- Review the details of the test results using a Browser. Open TestApp.xml which can be found in the sample_src directory (based on the output option). By opening the xml file in a web browser the xsl is automatically applied to create html.
Implement Exercise
- TestFixture::Exercise1
- Add a NOTEthat will display the name of the test
- Validate that Sequence2 is persisted when starting the Thread
- TestFixture::Exercise2
- Add new test method declaration called Exercise2 to TestFixture.h
- Add new test method implementation of Exercise2 to TestFixture.cpp
- Add a NOTE that will display the name of the test
- Validate that Sequence3 is persisted when starting the Thread
- Execute only TestFixture
> stride -O myoptions.txt --run TestFixture
Loading database... Connecting to device... Executing... test unit "TestFixture" > 3 passed, 0 failed, 0 in progress, 0 not in use. -------------------------------------------------------------- Summary: 3 passed, 0 failed, 0 in progress, 0 not in use. Disconnecting from device... Saving result file...
Run and Publish Results
When you have completed the Exercise(s) publish your results to Test Space. To make it easier for now we recommend that you update your existing option file (myoptions.txt) with the following if not already done:
#### Test Space options (partial) ##### #### Note - make sure to change username, etc. #### --testspace https://username:password@yourcompany.stridetestspace.com --project Training --name YOURNAME
> stride -O myoptions.txt --run TestFixture --space TestFixture --upload
Note: This space has been set up with a Baseline of expected test results that you can use to validate your results.
Reference
The following reference information is related to passing parameters to Test Units.
Wiki
- Fixturing Pragmas -- important information for setting up and tearing down things between each executed test method within a Test Unit
- Review the types of Test Units these pragmas are applicable for
Samples
- Test Class Sample - Specifically the Basic Fixtures Test Unit
- Test C Class Sample - Specifically the Basic Fixtures Test Unit
- Test Function List Sample- Specifically the Basic Fixtures Test Unit