Training Overview: Difference between revisions
No edit summary |
|||
(One intermediate revision by one other user not shown) | |||
Line 41: | Line 41: | ||
testfixtures.h | testfixtures.h | ||
A '''Perl''' module sample is provided an alternative approach when using ''Test Points'' | A '''Perl''' module sample is provided as an alternative approach when using ''Test Points'' | ||
testpoints.pm | testpoints.pm | ||
Line 92: | Line 92: | ||
It might be a good idea to create an option file for re-running tests going forward. For more details on running refer to the [[Stride Sandbox]] article. | It might be a good idea to create an option file for re-running tests going forward. For more details on running refer to the [[Stride Sandbox]] article. | ||
Example options file (my.opt) | '''Example options file (my.opt)''' | ||
--database "%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" | --database "%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" |
Latest revision as of 16:05, 27 November 2014
Our training approach is based on a self-guided tour of the Stride testing features using example source and suggesting things to try out. The Stride Sandbox will be used for the training.
The software under test and reference source has been designed to be as simple as possible while sufficiently demonstrating the topic at hand. In particular, the software under test is very light on core application logic -- the focus instead is on showcasing the testing features of Stride that can be applied.
The user is expected to
- Review both the application being tested and the test code (it is simple stuff)
- Read the associated wiki articles
- Look at the test reports, the descriptions provide more context
- Try Stuff .. the most important thing. Go ahead and make changes -- the edit-build-test is quick. The Stride Sandbox has been designed to make the change cycle fast and easy.
The training has been organized into Basics, Advanced, and an optional Perl usage model.
Source
The following source files can be found at /stride/samples
The software under test is contained in the file software_under_test.c | h. All of the public functions use sut_ as a prefix. All samples test against this module.
software_under_test.c software_under_test.h
Although the test samples are contained in C++ files, most of the test logic is written in standard C with a little bit of C++ added in.
These sample files are used to demonstrate the Basics in Stride testing features
testmacros.cpp testmacros.h testparameters.cpp testparameters.h testparameters.ini testfileio.cpp testfileio.h testfileio.ini testfileio.input.add
The next set of files focus on more Advanced testing techniques
testdoubles.cpp testdoubles.h testpoints.cpp testpoints.h testfixtures.cpp testfixtures.h
A Perl module sample is provided as an alternative approach when using Test Points
testpoints.pm
and a schema file used when leveraging Testspace
test-schema.xml
Building
To build using the samples use the following command
"%STRIDE_DIR%\SDK\Windows\bin\make" -C "%STRIDE_DIR%\SDK\Windows\src" SAMPLESDIR="%STRIDE_DIR%\samples" testapp
or for Linux/FreeBSD use
make -C "$STRIDE_DIR/SDK/Posix/src" SAMPLESDIR="$STRIDE_DIR/samples" testapp
It might be a good idea to create a batch file/shell script for re-building going forward. For more details on building refer to the Stride Sandbox article.
Running
To run using the samples use the following steps
- Start the application (TestApp executable)
%STRIDE_DIR%\SDK\Windows\out\bin\TestApp
or for Linux/FreeBSD
$STRIDE_DIR/SDK/Posix/out/bin/TestApp
Note the TestApp's console output upon starting.
-------------------------------------------------- STRIDE Test Console Application. Enter 'Ctrl+C' to Quit. -------------------------------------------------- starting up... Listening on TCP port 8000 "_srThread" thread started. "stride" thread started.
- Invoke the Runner (aka stride) from a second console
stride --database="%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" --device=TCP:localhost:8000 --run="*"
or for Linux/FreeBSD
stride --database="$STRIDE_DIR%/SDK/Posix/out/TestApp.sidb" --device=TCP:localhost:8000 --run="*"
It might be a good idea to create an option file for re-running tests going forward. For more details on running refer to the Stride Sandbox article.
Example options file (my.opt)
--database "%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" --device TCP:localhost:8000
stride --options_file my.opt --run "*"
Same applies for Linux/FreeBSD.
Running without any changes to the samples source code should look like the following on the console
Executing... Connecting to device (TCP:localhost:8000)... test suite "/TestDoubles" > 3 passed, 0 failed, 0 in progress, 0 unknown, 1 not in use, 67.01 ms. test suite "/TestFileIO" > 0 passed, 1 failed, 0 in progress, 0 unknown, 1 not in use, 47.01 ms. test suite "/TestFixtures" > 1 passed, 0 failed, 0 in progress, 0 unknown, 1 not in use, 246.02 ms. test suite "/TestMacros" > 1 passed, 0 failed, 0 in progress, 0 unknown, 1 not in use, 43.01 ms. test suite "/TestParameters" > 0 passed, 2 failed, 0 in progress, 0 unknown, 1 not in use, 51.01 ms. test suite "/TestPoints" > 3 passed, 0 failed, 0 in progress, 0 unknown, 1 not in use, 366.04 ms. Disconnecting from device... --------------------------------------------------------------------- Summary: 8 passed, 3 failed, 0 in progress, 0 unknown, 6 not in use, 820.08 ms.
- Bring up results in your browser
As a result of the run a report stride.xml is generated (this file is created in the directory from which you ran stride or at the path specified via the --output command line option). In addition a stride.html is generated that could be open in a web browser of your choice.