Difference between revisions of "C/C++ Samples"

From STRIDE Wiki
Jump to: navigation, search
(Test Points)
Line 1: Line 1:
These samples are a  collection of source code that demonstrate the techniques for creating and executing target-based (native code) tests using the STRIDE Framework. These are samples that implement the test logic using native code that executes on target. This functionality is focused at developers interested in writing tests in c/c++.
+
These samples are a  collection of source code that demonstrate the techniques for creating and executing target-based (native code) tests using the STRIDE Framework. These are samples that implement the test logic using native code that executes on target. This functionality is focused at developers interested in writing tests in C/C++.
  
Once you have installed the STRIDE Framework on your host machine, you can easily build and run any combination of these samples. In each case, you can include a sample simply by copying its source files to the SDK's [[Framework_Installation#SDK | sample_src]]  directory and rebuilding the off-target testapp.
+
Once you have installed the STRIDE Framework on your host machine, you can easily build and run any combination of these samples. In each case, you can include a sample simply by copying its source files to the SDK's [[Framework_Installation#SDK | sample_src]]  directory and rebuilding the off-target testapp.
  
  
 
== Introductory  Samples ==
 
== Introductory  Samples ==
This is the place  to start for on target tests in native code. These samples are meant to  serve as a basic overview of many native testing features and  techniques. If you are interested in writing tests in c/c++ that run on  the device, we recommend building and running these tests, then reviewing the test source code test output.
+
This is the place  to start for on target tests in native code. These samples are meant to  serve as a basic overview of many native testing features and  techniques. If you are interested in writing tests in C/C++ that run on  the device, we recommend building and running these tests, then reviewing the test source code test output.
  
 
;[[Test Intro  Sample]]
 
;[[Test Intro  Sample]]
: For C-only  environments this is the place to start. These samples are meant to  serve as a basic overview of many STRIDE testing features and techniques from a C perspective. If you haven't already done so, we recommend  building and running these tests, then reviewing the test source code  test output. The process of including this sample as well as running it  and publishing results is covered in [[Running and Publishing the TestIntro Sample]], which comprised an optional earlier step in the sandbox setup.
+
: For C-only  environments this is the place to start. These samples are meant to  serve as a basic overview of many STRIDE testing features and techniques from a C perspective. If you haven't already done so, we recommend  building and running these tests, then reviewing the test source code  test output. The process of including this sample as well as running it  and publishing results is covered in [[Running and Publishing the TestIntro Sample]], which comprised an optional earlier step in the sandbox setup.
  
 
;[[Test Intro Cpp  Sample]]
 
;[[Test Intro Cpp  Sample]]
: For C++  environments this is the place to start. The samples provide a basic  overview of many STRIDE testing features and techniques from a C++ perspective.
+
: For C++  environments this is the place to start. The samples provide a basic  overview of many STRIDE testing features and techniques from a C++ perspective.
  
 
== Test Unit Packaging ==
 
== Test Unit Packaging ==
''Test Unit  Packaging'' refers to how  functions or methods implementing test cases are packaged into test  units. It's possible for different packaging options to coexist, but for  consistency and simplicity, we recommend that you decide early on in  your test creation cycle what kind of test unit package you will use for your test units and then stick with that for all of your test units.
+
''Test Unit  Packaging'' refers to how  functions or methods implementing test cases are packaged into test  units. It's possible for different packaging options to coexist, but for  consistency and simplicity, we recommend that you decide early on in  your test creation cycle what kind of test unit package you will use for your test units and then stick with that for all of your test units.
  
If  your compiler supports standard C++, the ''Test Class'' packaging is preferred as it allows the greatest functionality and flexibility with no added complexity for the simplest use cases.<ref>If your C++ compiler supports exceptions and/or namespaces, STRIDE can take  advantage of the added capabilities, but these <u>are not</u> required</ref> (Note that the Test Class packaging can be used even if the software under test is written in C.)
+
If  your compiler supports standard C++, the ''Test Class'' packaging is preferred as it allows the greatest functionality and flexibility with no added complexity for the simplest use cases.<ref>If your C++ compiler supports exceptions and/or namespaces, STRIDE can take  advantage of the added capabilities, but these <u>are not</u> required</ref> (Note that the Test Class packaging can be used even if the software under test is written in C.)
  
If you have selected the type of test unit you will be using, we recommend you review and run the corresponding sample. If you are still deciding which type of test unit packaging to use, feel free to peruse all three samples as well as the corresponding [[Test Units|documentation]].
+
If you have selected the type of test unit you will be using, we recommend you review and run the corresponding sample. If you are still deciding which type of test unit packaging to use, feel free to peruse all three samples as well as the corresponding [[Test Units|documentation]].
  
 
;[[Test_Class_Samples  | Test  Class Samples]] ''(C++ only)''
 
;[[Test_Class_Samples  | Test  Class Samples]] ''(C++ only)''
: Demonstrates features available when [[Test Units|test units]] are created as C++ classes
+
: Demonstrates features available when [[Test Units|test units]] are created as C++ classes
 
;[[Test_CClass_Samples | Test C Class  Samples]]
 
;[[Test_CClass_Samples | Test C Class  Samples]]
: Demonstrates how to create and use [[Test Units|test units]] that are C structures
+
: Demonstrates how to create and use [[Test Units|test units]] that are C structures
 
;[[Test_Function_List_Samples  | Test  Function List Samples]]
 
;[[Test_Function_List_Samples  | Test  Function List Samples]]
: Demonstrates how to create and use [[Test Units|test units]] that are free C functions
+
: Demonstrates how to create and use [[Test Units|test units]] that are free C functions
  
 
== Common Testing  Features ==
 
== Common Testing  Features ==
These samples  demonstrate features that are frequently used in common testing  scenarios. All developers creating or maintaining tests should be familiar with the techniques shown in these samples.
+
These samples  demonstrate features that are frequently used in common testing  scenarios. All developers creating or maintaining tests should be familiar with the techniques shown in these samples.
  
 
===Pass/Fail Macros===
 
===Pass/Fail Macros===
Pass/Fail Macros simplify the  task of setting a test case's status to pass or fail. They comprise a  set of ASSERTs and EXPECTs that test a condition (e.g. equailty, less  than, strings equal, etc.) and set the currently running test to the  appropriate pass or fail status. ASSERTs cause the currently executing function to immediately return if fail status is set; EXPECTs do not return.
+
Pass/Fail Macros simplify the  task of setting a test case's status to pass or fail. They comprise a  set of ASSERTs and EXPECTs that test a condition (e.g. equailty, less  than, strings equal, etc.) and set the currently running test to the  appropriate pass or fail status. ASSERTs cause the currently executing function to immediately return if fail status is set; EXPECTs do not return.
 
   
 
   
 
;[[Test_Macros_Samples  | Test  Macros Samples]]
 
;[[Test_Macros_Samples  | Test  Macros Samples]]
: Demonstrates  the use of the [[Test Code Macros]]. This sample is implemented using Test Classes (''c++ only''), but these macros also work in C compilation units.
+
: Demonstrates  the use of the [[Test Code Macros]]. This sample is implemented using Test Classes (''C++ only''), but these macros also work in C compilation units.
  
 
==Advanced Testing Features==
 
==Advanced Testing Features==
The features demonstrated in these samples target specific testing problems.
+
The features demonstrated in these samples target specific testing problems.
  
 
===Test Points===
 
===Test Points===
Test points are a unique STRIDE feature that greatly simplifies testing of multi-threaded software as well as single-threaded software that employs callbacks.
+
Test points are a unique STRIDE feature that greatly simplifies testing of multi-threaded software as well as single-threaded software that employs callbacks.
  
 
;[[Test  Point Samples]]
 
;[[Test  Point Samples]]
: Demonstrates  techniques and syntax for implementing [[Test Point Testing in C/C++ |Test Points]]. With this technique, STRIDE makes it possible to observe and verify activity occurring another thread (e.g. a state machine).
+
: Demonstrates  techniques and syntax for implementing [[Test Point Testing in C/C++ |Test Points]]. With this technique, STRIDE makes it possible to observe and verify activity occurring another thread (e.g. a state machine).
  
 
===Test Doubles===
 
===Test Doubles===
Line 49: Line 49:
  
 
;[[Test_Double_Samples  | Test  Double Samples]]
 
;[[Test_Double_Samples  | Test  Double Samples]]
: Demonstrates  techniques and syntax for implementing [[Using Test  Doubles|Test Doubles]]. STRIDE's unique implementation makes it possible to dynamically switch in function mocks, stubs, and fakes at runtime. This sample is implemented using Test Classes (''c++ only''), but the techniques demonstrated work equally well in C compilation units.
+
: Demonstrates  techniques and syntax for implementing [[Using Test  Doubles|Test Doubles]]. STRIDE's unique implementation makes it possible to dynamically switch in function mocks, stubs, and fakes at runtime. This sample is implemented using Test Classes (''C++ only''), but the techniques demonstrated work equally well in C compilation units.
  
 
===File Services===
 
===File Services===
The STRIDE File Services APIs provide a means to perform basic filesystem operations on the host  filesystem from test code running on a device.  
+
The STRIDE File Services APIs provide a means to perform basic filesystem operations on the host  filesystem from test code running on a device.  
  
 
;[[File_Services_Samples  | File  Services Samples]]
 
;[[File_Services_Samples  | File  Services Samples]]

Revision as of 18:37, 7 June 2010

These samples are a collection of source code that demonstrate the techniques for creating and executing target-based (native code) tests using the STRIDE Framework. These are samples that implement the test logic using native code that executes on target. This functionality is focused at developers interested in writing tests in C/C++.

Once you have installed the STRIDE Framework on your host machine, you can easily build and run any combination of these samples. In each case, you can include a sample simply by copying its source files to the SDK's sample_src directory and rebuilding the off-target testapp.


Introductory Samples

This is the place to start for on target tests in native code. These samples are meant to serve as a basic overview of many native testing features and techniques. If you are interested in writing tests in C/C++ that run on the device, we recommend building and running these tests, then reviewing the test source code test output.

Test Intro Sample
For C-only environments this is the place to start. These samples are meant to serve as a basic overview of many STRIDE testing features and techniques from a C perspective. If you haven't already done so, we recommend building and running these tests, then reviewing the test source code test output. The process of including this sample as well as running it and publishing results is covered in Running and Publishing the TestIntro Sample, which comprised an optional earlier step in the sandbox setup.
Test Intro Cpp Sample
For C++ environments this is the place to start. The samples provide a basic overview of many STRIDE testing features and techniques from a C++ perspective.

Test Unit Packaging

Test Unit Packaging refers to how functions or methods implementing test cases are packaged into test units. It's possible for different packaging options to coexist, but for consistency and simplicity, we recommend that you decide early on in your test creation cycle what kind of test unit package you will use for your test units and then stick with that for all of your test units.

If your compiler supports standard C++, the Test Class packaging is preferred as it allows the greatest functionality and flexibility with no added complexity for the simplest use cases.[1] (Note that the Test Class packaging can be used even if the software under test is written in C.)

If you have selected the type of test unit you will be using, we recommend you review and run the corresponding sample. If you are still deciding which type of test unit packaging to use, feel free to peruse all three samples as well as the corresponding documentation.

Test Class Samples (C++ only)
Demonstrates features available when test units are created as C++ classes
Test C Class Samples
Demonstrates how to create and use test units that are C structures
Test Function List Samples
Demonstrates how to create and use test units that are free C functions

Common Testing Features

These samples demonstrate features that are frequently used in common testing scenarios. All developers creating or maintaining tests should be familiar with the techniques shown in these samples.

Pass/Fail Macros

Pass/Fail Macros simplify the task of setting a test case's status to pass or fail. They comprise a set of ASSERTs and EXPECTs that test a condition (e.g. equailty, less than, strings equal, etc.) and set the currently running test to the appropriate pass or fail status. ASSERTs cause the currently executing function to immediately return if fail status is set; EXPECTs do not return.

Test Macros Samples
Demonstrates the use of the Test Code Macros. This sample is implemented using Test Classes (C++ only), but these macros also work in C compilation units.

Advanced Testing Features

The features demonstrated in these samples target specific testing problems.

Test Points

Test points are a unique STRIDE feature that greatly simplifies testing of multi-threaded software as well as single-threaded software that employs callbacks.

Test Point Samples
Demonstrates techniques and syntax for implementing Test Points. With this technique, STRIDE makes it possible to observe and verify activity occurring another thread (e.g. a state machine).

Test Doubles

Test doubles provide a means to intercept function calls so that alternate implementations can be substituted at runtime under the control of your test code. This enables sophisticated mocking, faking, and stubbing.

Test Double Samples
Demonstrates techniques and syntax for implementing Test Doubles. STRIDE's unique implementation makes it possible to dynamically switch in function mocks, stubs, and fakes at runtime. This sample is implemented using Test Classes (C++ only), but the techniques demonstrated work equally well in C compilation units.

File Services

The STRIDE File Services APIs provide a means to perform basic filesystem operations on the host filesystem from test code running on a device.

File Services Samples
Demonstrates techniques and syntax for performing basic tasks using the File Transfer Services API.

Notes

  1. If your C++ compiler supports exceptions and/or namespaces, STRIDE can take advantage of the added capabilities, but these are not required