Building an Off-Target Test App

From STRIDE Wiki
Revision as of 15:08, 6 June 2011 by Marku (talk | contribs) (Created page with '== Introduction == This article guides you through building a test application for the purpose of running sample code using the STRIDE [[Installation_Overview#Off-Target_Environm…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

This article guides you through building a test application for the purpose of running sample code using the STRIDE Off-Target Environment.

It requires an installation of the STRIDE Framework package. If not installed, please see Desktop Installation for more information.

Host Toolchain

To simplify our training (and executing our Samples), we leverage a single Windows or Linux (x86) computer for both the target and host systems. Host and target code will run in separate processes and communicate via TCP/IP, thus simulating an embedded target with host computer configuration. All code and techniques used in the Off-Target Environment are directly transferable to a production environment.

Please complete and verify the Host system development toolchain installation:

  • For Windows Microsoft Visual Studio 2005 or later is required. If you don't already have Visual Studio, the free Visual C++ Express can be used (download here).
  • For Linux the GNU Compiler Collection (included by default in almost all Linux distros) is required.


Building a TestApp

SDK Makefile

The SDK Makefile is set up so that all .c .cpp and .h files found in the directory 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 STRIDE Build Tools. This will result in

  • the detection of test pragmas used to declare Test Units in these .h files
  • the detection of function pragmas used to declare remoting of functions also found in .h files
  • the inclusion of metadata into the sidb file created
  • the generation of an Intercept Module required for executing tests

Build Steps

To begin, be sure that TestApp is not running then perform the following steps:

Linux

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

Windows

NOTE: If you have Cygwin installed and its bin directory is on your path, see Troubleshooting Build Problems.

  1. If using Microsoft Visual Studio, open a Visual Studio command prompt[1] 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_DIR%\SDK\Windows\src
    ..\bin\make testapp
    
  3. The file %STRIDE_DIR%\SDK\Windows\out\bin\TestApp.exe will be produced
  4. Note that the STRIDE database file %STRIDE_DIR%\SDK\Windows\out\TestApp.sidb is also produced

Note: If you prefer to use Visual Studio to build/debug/run your testapp, we provide instructions here about how to accomplish this.

Diagnostics

A set of diagnostic tests are always built into the generated TestApp executable. If desired (we recommend you to do so) you could run them by doing the following:

  1. Invoke the TestApp. In order to see TestApp's output, we recommend that you manually open a new console (or Windows equivalent):
    Linux
    $STRIDE_DIR/SDK/Linux/out/bin/TestApp
    
    Windows
    %STRIDE_DIR%\SDK\Windows\out\bin\TestApp
    

    (...or launch from the file explorer)

  2. Note TestApp's output upon startup.
    --------------------------------------------------
    STRIDE Test Console Application.
    Enter 'Q' to Quit.
    --------------------------------------------------
    starting up...
    Listening on TCP port 8000
    "_srThread" thread started.
    "stride" thread started.
    
  3. From a console window, invoke stride as follows, to verify connectivity with the target app (or Windows equivalent):
    Linux
    stride --diagnostics --database=$STRIDE_DIR/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000 --run="*"
    
    Windows
    stride --diagnostics --database=%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb --device=TCP:localhost:8000 --run="*"
    

    As the tests run you will see output in both the TestApp (target) and stride (host) console windows.

    The host console window output is shown here:

    Loading database...
    Connecting to device...
      runtime version: 4.2.0x 
    Executing diagnostics...
      test unit "Link"
        Loopback ............
        Payload Fragmentation
        Stub-Proxy Deadlock
        Target Characteristics
        > 4 passed, 0 failed, 0 in progress, 0 not in use.
      test unit "Stat"
        > 2 passed, 0 failed, 0 in progress, 0 not in use.
      test unit "Time"
        > 2 passed, 0 failed, 0 in progress, 0 not in use.
      --------------------------------------------------------------------- 
      Summary: 8 passed, 0 failed, 0 in progress, 0 not in use.
    
    Disconnecting from device...
    Saving result file...
    
  4. Note the Summary results shown in the host output; all in use tests should pass.
  5. To exit TestApp, give the target window focus and enter Ctrl-C (or 'q' under Windows).


TestIntro Sample

The initial desktop installation of STRIDE does not set up any source code (with the exception of a set of system diagnostic tests) for automatic inclusion in a test application. The desktop framework distribution, however, comes with a set of Samples.

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.

To begin, be sure that TestApp is not running, then copy the .c and .h files found in Samples/test_in_c_cpp/TestIntro to SDK/Windows/sample_src (or SDK/Linux/sample_src for Linux).

Once the files have been copied to sample_src, simply build TestApp as described above. Note if you had previous copied other sample source to this directory, you should decide whether to remove those files first. When you complete the test app build, any source that is in this directory at the time of build will be included in the test app.

Running the Tests

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

  1. Run the build above TestApp in a console window.
  2. Invoke stride in a separate console window (different from the running TestApp) -- as shown below and verify Summary results.

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

--database ./out/TestApp.sidb 
--device TCP:localhost:8000

A couple of things to note:

  • If you setup environment variables for the device option that is is not required in the option file. Note: Command line options override environment variables.
  • You may want to create a text file named RunTestIntro.txt in the SDK\Windows (or SDK/Linux for Linux) directory as an option 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 (starting from the SDK\Windows or SDK/Linux directory):

stride -O RunTestIntro.txt --run="*"

The output should look like this:

Loading database...
Connecting to device...
Executing...
  test unit "s2_testintro_flist"
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_cclass"
    > 1 passed, 1 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_testdoubles"
    > 3 passed, 0 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_testpoints"
    > 3 passed, 0 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_parameters"
    > 2 passed, 0 failed, 0 in progress, 0 not in use.
  --------------------------------------------------------------------- 
  Summary: 11 passed, 2 failed, 0 in progress, 0 not in use.

Disconnecting from device...
Saving result file...

Interpreting Results

If you're interested in the details of the tests, please see to the test documentation contained in the test report. Open TestApp.xml in your browser; this file is created in the directory from which you ran stride. If you were connected to the Internet when you ran the tests, the TestApp.xsl file is also generated in the directory. By opening TestApp.xml in a web browser, the xsl is automatically applied to create html in the browser.


Notes

  1. To open a Visual Studio Command prompt: Click the Start button, point to All Programs, Microsoft Visual Studio 200X, Visual Studio Tools, and then click Visual Studio 200X Command Prompt.
  2. Note that the S2 diagnostic tests are treated separately, and are not run unless the --diagnostics option is specified to stride.