Test Double Sample: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
==Introduction==
==Introduction==
The Test Double Sample is part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]], and '''''is only available in the Beacon's release or later'''''. The following content relates to the sample files and workspaces installed in '''<tt>%STRIDE_DIR%\Samples\TestUnits\TestDouble</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 source code (C and C++ implementations),  and a STRIDE workspace for doing more advanced test execution.
The Test Double Sample is part of the [[Test_Unit_Samples|STRIDE Test Unit Samples]].


==Getting Started==
== Building and Running the Samples ==
Please refer to the section appropriate for your target build environment:


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].
*[[Building and Running Test Unit Samples Under Windows| Windows Off-Target]]  


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.
*[[Building and Running Test Unit Samples Under Linux|Linux]]


Once the build is complete, perform the following steps to run the test classes in the workspace:
*[[Building and Running Test Unit Samples Under WinMobile|WinMobile]]
 
# launch the Windows Off-Target App, TestDouble.exe.  This will run in a standard console window.
# open a command prompt window and change to this sample's directory.
# 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.
# quit the TestDouble.exe application by typing 'q' in its console window.


==Test Double Sample==
==Test Double Sample==


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 double source and the corresponding results that each produces.  This section provides a brief description for each. <br>'''''Note:''''' It is recommended that you read the [[Function Double]] article before proceeding in order to understand the concepts.
Once you have built the sample target application and executed its tests, you can take time to peruse the test double source and the corresponding results that each produces.  This section provides a brief description for each. <br>'''''Note:''''' It is recommended that you read the [[Using Test Doubles]] article before proceeding in order to understand the concepts.


===01_01_Cpp_Test_Function===
===01_01_Cpp_Test_Function===

Revision as of 17:13, 20 April 2009

Introduction

The Test Double Sample is part of the STRIDE Test Unit Samples.

Building and Running the Samples

Please refer to the section appropriate for your target build environment:

Test Double Sample

Once you have built the sample target application and executed its tests, you can take time to peruse the test double source and the corresponding results that each produces. This section provides a brief description for each.
Note: It is recommended that you read the Using Test Doubles article before proceeding in order to understand the concepts.

01_01_Cpp_Test_Function

This example uses a C++ test class to validate the test_func1 function under test. The dependency depend1 is left in place during the CallNoDoubling method. The dependency is replaced with a fake method, which simply returns a constant in the CallWithFake method. The dependency is replaced with a mock method, which validates the passed in parameter, in the CallWithMock method.
The intercept mangling parameters in this example, in the scl_function pragma, uses the "DEFINITION" option to indicate the the intercept will be at the function definition, and the"IMPLICIT" option because no mangling is required to intercept (because the caller and callee are in separate compilation units).

01_02_Cpp_Test_Function_With_Depend

This example uses a C++ test class to validate the test_func2 function under test. The dependency depend2 is left in place during the CallNoDoubling method. The dependency is replaced with a fake method, which simply returns a constant in the CallWithFake method. The dependency is replaced with a mock method, which validates the passed in parameter, in the CallWithMock method.
The intercept mangling parameters in this example, in the scl_function pragma, uses the "REFERENCE" option to indicate the the intercept will be at the function call, and the"EXPLICIT" option because mangling is required to intercept (because the caller and callee reside in the same source file).

02_01_C_Test_Function

This example uses a C test class to validate the test_func1 function under test. The dependency depend1 is left in place during the CallNoDoubling method. The dependency is replaced with a fake method, which simply returns a constant in the CallWithFake method. The dependency is replaced with a mock method, which validates the passed in parameter, in the CallWithMock method.
The intercept mangling parameters in this example, in the scl_function pragma, uses the "DEFINITION" option to indicate the the intercept will be at the function definition, and the"IMPLICIT" option because no mangling is required to intercept (because the caller and callee are in separate compilation units).

02_02_C_Test_Function_With_Depend

This example uses a C test class to validate the test_func2 function under test. The dependency depend2 is left in place during the CallNoDoubling method. The dependency is replaced with a fake method, which simply returns a constant in the CallWithFake method. The dependency is replaced with a mock method, which validates the passed in parameter, in the CallWithMock method.
The intercept mangling parameters in this example, in the scl_function pragma, uses the "REFERENCE" option to indicate the the intercept will be at the function call, and the"EXPLICIT" option because mangling is required to intercept (because the caller and callee reside in the same source file).

Command Line Execution

Command line execution for the Test Double sample is done using the TestUnitRun utility. Here are several examples of specific syntax to execute the sample. All of these commands can be invoked from a standard 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 TestDouble.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).

Simple execution of all test units

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.

 TestUnitRun.pl -d TestDouble.sidb

This command executes all Test Units found in the database in descending alpha-numeric sort order. Any Test Unit initialization arguments are given default values (typically zero or NULL).

When you run this command, you should see console output like:

Attempting connection using [Sockets (S2)] transport ...
Connected to device.
Initializing STRIDE database objects...
Done.
Running Test C_Test_Function...
Running Test C_Test_Function_With_Depend...
Running Test CppTestFunction...
Running Test CppTestFunctionWithDepend...
Disconnected from device.
Test Results saved to C:\STRIDE\Samples\TestUnits\TestDouble\TestDouble.xml
Test Report saved to C:\STRIDE\Samples\TestUnits\TestDouble\TestDouble.html
***************************************************************************
Results Summary
***************************************************************************
  Passed:              12
  Failed:               0
  In Progress:          0
  Not Applicable:       0
  ...in 4 suites.
***************************************************************************

Workspace-based Execution

TestDouble.ssw, a workspace in the TestDouble 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 (TestDouble.exe) and to manage traceviews used for srPrint message collection. The scripts that drive the testing are in the workspace test folder. What follows is a brief description for each.

RunAll

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 ArrangeBy collection method was called.

Run Individual

This folder shows how to use individual scripts to execute test classes. Each script has the following form:

 ascript.TestUnits.Item(TEST_UNIT_NAME).Run();

The TEST_UNIT_NAME is the name of the test unit to be run. The order and hierarchy of each script may be changed via the Studio tree control by moving the script within the Run Individual folder.