Running and Publishing the TestIntro Sample: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
Line 4: Line 4:
This step requires an installation of the STRIDE Samples package. If not installed, please see [[Package_Installation#Samples|Package Installation]] for more information.
This step requires an installation of the STRIDE Samples package. If not installed, please see [[Package_Installation#Samples|Package Installation]] for more information.


The SDK Makefile is set up so that all .c .cpp and .h files found in the directory <tt>SDK/Linux/sample_src</tt> (or, alternatively <tt>SDK\Windows\sample_src</tt>) are included in the compile and link of the '''testapp''' target.
=== How the SDK Makefile Includes Tests ===
The SDK Makefile is set up so that all <tt>.c</tt> <tt>.cpp</tt> and <tt>.h</tt> files found in the directory <tt>SDK/Linux/sample_src</tt> (or, alternatively <tt>SDK\Windows\sample_src</tt>) are included in the compile and link of the '''testapp''' target.


Further--as a pre-compilation step--any .h files found in <tt>sample_src</tt> are submitted to the [[s2scompile|S2 compiler]] and subsequent [[Build Tools]]. This will result in  
Further--as a pre-compilation step--any <tt>.h</tt> files found in <tt>sample_src</tt> are submitted to the [[s2scompile|S2 compiler]] and subsequent [[Build Tools]]. This will result in  
* the detection of [[SCL Pragmas#Test_Units| SCL Pragmas]] which declare Test Units in these .h files
* the detection of [[SCL Pragmas#Test_Units| SCL Pragmas]] which declare Test Units in these <tt>.h</tt> files
* the inclusion of metadata into the sidb file to describe these Test Units
* the inclusion of metadata into the sidb file to describe these Test Units
* the generation of test harnessing code to run the indicated Test Units and collect results
* the generation of test harnessing code to run the indicated Test Units and collect results


To begin, be sure that TestApp is not running, then copy the .c and .h files found in <tt>Samples/TestIntro</tt> to <tt>SDK/Linux/sample_src</tt> (or Windows equivalent). Then [[Building_the_Basic_TargetApp_and_Running_Diagnostics#Building_the_TestApp|build the TestApp]] as described in previous evaluation steps.


== Listing Test Units in the Database File ==
=== Build Steps ===
In this step, we will use stride to list the Test Units in the <tt>TestApp.sidb</tt> database.
To begin, be sure that TestApp is not running, then copy the <tt>.c</tt> and <tt>.h</tt> files found in <tt>Samples/TestIntro</tt> to <tt>SDK/Linux/sample_src</tt> (or Windows equivalent). As described above, the presence of these files in the <tt>sample_src</tt> will result in the submission of the <tt>.h</tt> files to the STRIDE Build Tools (thus generating test harnessing code from the scl pragmas found within them) and inclusion of both the sources and the generated harnessing code in the build.


Run stride as follows (or Windows equivalent):
Once the files have been copied to <tt>sample_src</tt>, simply build testapp using the SDK makefile.
====Linux====
<ol>
<li>Build the test app
<source lang="bash">
<source lang="bash">
stride --list --database=~/stride/SDK/Linux/out/TestApp.sidb
cd ~/stride/SDK/Linux/src
make testapp
</source>
</source>
</li>
<li>The file <tt>~/stride/SDK/Linux/out/bin/TestApp</tt> will be produced
</li>
<li>Note also that the STRIDE database file <tt>~/stride/SDK/Linux/out/TestApp.sidb</tt> is also produced
</li>
</ol>
 
====Windows====
<ol>
<li>If using Microsoft Visual Studio, open a Visual Studio command prompt to ensure that the compiler and linker are on your PATH.
</li>
<li>Build the test app using the supplied GNU make. (You will get Makefile errors if you use the default make.)
<source lang="dos">
cd stride\SDK\Windows\src
..\bin\make testapp
</source>
</li>
<li>The file <tt>stride\SDK\Windows\out\bin\TestApp.exe</tt> will be produced
</li>
<li>Note that the STRIDE database file <tt>stride\SDK\Windows\out\TestApp.sidb</tt> is also produced
</li>
</ol>
== Running Test Intro Samples and Publishing Results to Test Space ==
Here we will run all tests in the <tt>TestApp.sidb</tt> database.<ref>Note that the S2 diagnostic tests are treated separately, and are not run unless the <tt>--diagnostics</tt> option is specified to <tt>stride</tt>.</ref>
# Run TestApp in a console window as in earlier steps.
# Invoke <tt>stride</tt> as shown below and verify Summary results.


You should see output like this:
Here are the command line parameters that we will submit to <tt>stride</tt>


<pre>
<pre>
s2_testintro_cclass
--database TestApp.sidb
s2_testintro_flist
--device TCP:localhost:8000
s2_testintro_testdoubles
--upload
s2_testintro_testpoints
--testspace https://USER:PASS@mycompany.stridetestspace.com
--project Sandbox
--space TestIntro
</pre>
</pre>


Note that the S2 diagnostic tests (which are also present in this TestApp) are not shown in the list of Test Units.
A couple of things to note:
* You will have to replace ''USER:PASS'' with your S2-assigned TestSpace user name and password
* You will have to replace ''mycompany'' with your S2-assigned subdomain name
* The project "Sandbox" and TestSpace "TestIntro" have been pre-created within your company STRIDE TestSpace


== Running Test Intro Samples and Publishing Results to Test Space ==
The command line is very long, so we'll want to create a text file named ''RunTestIntro.txt'' in the <tt>out</tt> directory as a command file to submit to <tt>stride</tt>.
 
If you haven't done so already, start <tt>TestApp</tt> running in a separate console window.


=== Running All Tests ===
Here we will run all tests in the <tt>TestApp.sidb</tt> database.<ref>Note that the S2 diagnostic tests are treated separately, and are not run unless the <tt>--diagnostics</tt> option is specified to <tt>stride</tt>.</ref>


# Invoke TestApp in a target console as in earlier steps.
Now run stride as follows:
# Invoke <tt>stride</tt> as shown below and verify Summary results.


<source lang="bash">
<source lang="bash">
stride --database=~/stride/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000
stride -O RunTestIntro.txt
</source>
</source>
The output should look like this:
<pre>
<pre>
Loading database...
Loading database...
Line 49: Line 89:
Executing test units...
Executing test units...
   s2_testintro_cclass
   s2_testintro_cclass
     > 1 passed, 1 failed, 0 in progress, 0 not in use.
     > 1 passed, 1 failed, 0 in progress, 0 not in use (109 msec).
   s2_testintro_flist
   s2_testintro_flist
     > 2 passed, 1 failed, 0 in progress, 0 not in use.
     > 2 passed, 1 failed, 0 in progress, 0 not in use (156 msec).
   s2_testintro_testdoubles
   s2_testintro_testdoubles
     > 3 passed, 0 failed, 0 in progress, 0 not in use.
     > 3 passed, 0 failed, 0 in progress, 0 not in use (16 msec).
   s2_testintro_testpoints
   s2_testintro_testpoints
     > 3 passed, 0 failed, 0 in progress, 0 not in use.
     > 3 passed, 0 failed, 0 in progress, 0 not in use (109 msec).
   ---------------------------------------------------------------------
   ---------------------------------------------------------------------
   Summary: 9 passed, 2 failed, 0 in progress, 0 not in use.
   Summary: 9 passed, 2 failed, 0 in progress, 0 not in use (390 msec).


Disconnecting from device...
Disconnecting from device...
Line 64: Line 104:
</pre>
</pre>


=== Running a Subset of Tests ===
=== Viewing Results in Test Space ===
Here we will run only the Test Units named <tt>s2_testintro_cclass</tt> and <tt>s2_testintro_flist</tt> against TestApp.
First navigate to the S2-provided TestSpace with your browser. The URL has the form: https://companyname.stridetestspace.com. On the page that is presented, enter your login credentials.
 
At the top of the next page, click on the All Projects link to view the status of existing projects. Here you should see the Sandbox project listed, with its contained TestSpace ''TestIntro'' shown.
 
Clicking the ''TestIntro'' link will present you with the ''TestIntro'' TestSpace page. From the top-line results at the bottom of the page you can drill down into the Sequence_1 results to see the test details.
 
=== Analyzing the Results ===
At this point, we recommend that you take some time to review the techniques used in the TestIntro sample tests and correlate the results shown in Test Space with the various STRIDE constructs in the sample source.
 
The following articles will be helpful in your analysis:


<source lang="bash">
*[[Test Intro Sample]]
stride -r "s2_testintro_cclass, s2_testintro_flist" --database=~/stride/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000
*[[Test Organization]]
</source>
*[[Test Unit Pragmas]]
<pre>
*[[Pass/Fail Macros]]
Loading database...
*[[Test Log Macros]]
Connecting to device...
*[[Test Points]]
  runtime version: 4.1.01
*[[Test Doubles]]
Executing test units...
  s2_testintro_cclass
    > 1 passed, 1 failed, 0 in progress, 0 not in use.
  s2_testintro_flist
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  ---------------------------------------------------------------------
  Summary: 3 passed, 2 failed, 0 in progress, 0 not in use.


Disconnecting from device...
Saving result file...
</pre>


<hr/>
<references/>
[[Category:For Evaluators...]]
[[Category:For Evaluators...]]

Revision as of 22:44, 1 September 2009

Building the TargetApp to Include Test Intro Sample

In this step, will will add a set of sample tests that provide an overview of STRIDE testing techniques. The Test Intro Sample tests are described in the linked article.

This step requires an installation of the STRIDE Samples package. If not installed, please see Package Installation for more information.

How the SDK Makefile Includes Tests

The SDK Makefile is set up so that all .c .cpp and .h files found in the directory SDK/Linux/sample_src (or, alternatively SDK\Windows\sample_src) are included in the compile and link of the testapp target.

Further--as a pre-compilation step--any .h files found in sample_src are submitted to the S2 compiler and subsequent Build Tools. This will result in

  • the detection of SCL Pragmas which declare Test Units in these .h files
  • the inclusion of metadata into the sidb file to describe these Test Units
  • the generation of test harnessing code to run the indicated Test Units and collect results


Build Steps

To begin, be sure that TestApp is not running, then copy the .c and .h files found in Samples/TestIntro to SDK/Linux/sample_src (or Windows equivalent). As described above, the presence of these files in the sample_src will result in the submission of the .h files to the STRIDE Build Tools (thus generating test harnessing code from the scl pragmas found within them) and inclusion of both the sources and the generated harnessing code in the build.

Once the files have been copied to sample_src, simply build testapp using the SDK makefile.

Linux

  1. Build the test app
    cd ~/stride/SDK/Linux/src
    make testapp
    
  2. The file ~/stride/SDK/Linux/out/bin/TestApp will be produced
  3. Note also that the STRIDE database file ~/stride/SDK/Linux/out/TestApp.sidb is also produced

Windows

  1. If using Microsoft Visual Studio, open a Visual Studio command prompt to ensure that the compiler and linker are on your PATH.
  2. Build the test app using the supplied GNU make. (You will get Makefile errors if you use the default make.)
    cd stride\SDK\Windows\src
    ..\bin\make testapp
    
  3. The file stride\SDK\Windows\out\bin\TestApp.exe will be produced
  4. Note that the STRIDE database file stride\SDK\Windows\out\TestApp.sidb is also produced


Running Test Intro Samples and Publishing Results to Test Space

Here we will run all tests in the TestApp.sidb database.[1]

  1. Run TestApp in a console window as in earlier steps.
  2. Invoke stride as shown below and verify Summary results.

Here are the command line parameters that we will submit to stride

--database TestApp.sidb 
--device TCP:localhost:8000
--upload
--testspace https://USER:PASS@mycompany.stridetestspace.com
--project Sandbox
--space TestIntro

A couple of things to note:

  • You will have to replace USER:PASS with your S2-assigned TestSpace user name and password
  • You will have to replace mycompany with your S2-assigned subdomain name
  • The project "Sandbox" and TestSpace "TestIntro" have been pre-created within your company STRIDE TestSpace

The command line is very long, so we'll want to create a text file named RunTestIntro.txt in the out directory as a command file to submit to stride.

If you haven't done so already, start TestApp running in a separate console window.


Now run stride as follows:

stride -O RunTestIntro.txt

The output should look like this:

Loading database...
Connecting to device...
  runtime version: 4.1.01
Executing test units...
  s2_testintro_cclass
    > 1 passed, 1 failed, 0 in progress, 0 not in use (109 msec).
  s2_testintro_flist
    > 2 passed, 1 failed, 0 in progress, 0 not in use (156 msec).
  s2_testintro_testdoubles
    > 3 passed, 0 failed, 0 in progress, 0 not in use (16 msec).
  s2_testintro_testpoints
    > 3 passed, 0 failed, 0 in progress, 0 not in use (109 msec).
  ---------------------------------------------------------------------
  Summary: 9 passed, 2 failed, 0 in progress, 0 not in use (390 msec).

Disconnecting from device...
Saving result file...
Uploading to test space...

Viewing Results in Test Space

First navigate to the S2-provided TestSpace with your browser. The URL has the form: https://companyname.stridetestspace.com. On the page that is presented, enter your login credentials.

At the top of the next page, click on the All Projects link to view the status of existing projects. Here you should see the Sandbox project listed, with its contained TestSpace TestIntro shown.

Clicking the TestIntro link will present you with the TestIntro TestSpace page. From the top-line results at the bottom of the page you can drill down into the Sequence_1 results to see the test details.

Analyzing the Results

At this point, we recommend that you take some time to review the techniques used in the TestIntro sample tests and correlate the results shown in Test Space with the various STRIDE constructs in the sample source.

The following articles will be helpful in your analysis:



  1. Note that the S2 diagnostic tests are treated separately, and are not run unless the --diagnostics option is specified to stride.