Test Integration

From STRIDE Wiki
Revision as of 01:09, 10 June 2009 by Timd (talk | contribs) (New page: In this article, we discuss establishment of continuous integration testing using STRIDE. The starting point of this article assumes that your have completed the steps described in the ar...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

In this article, we discuss establishment of continuous integration testing using STRIDE.

The starting point of this article assumes that your have completed the steps described in the article Test Integration.

Adding the TestIntro Tests to the Target Build

Here we will add the TestIntro sample tests to the target build. We suggest that you continue to include the STRIDE diagnostics in this build and all subsequent builds.

Copy the file s2_testintro_test.h to a designated SCL_DIRS directory (or alternative), include the TestIntro source files in the compile/link and perform a target build.

Download the binary to the target and start it running.

Running and Publishing the TestIntro Tests

To execute the TestIntro tests, use a Windows or Linux host computer that has connectivity with the target system via your configured STRIDE transport (TCP/IP or seral). Additionally, make the generated STRIDE database (.sidb) visible to the host computer via a shared filesystem or a file copy to the host system.

If not already present, install the appropriate Host Tools package on the host computer.

Run stride as follows:

-r /(*) 
--database [path]/stride.sidb 
--device arg 
-u
--testspace https://mycompany.stridetestspace.com@user:pwd
--project stride_deployment
--space TestIntro
stride -o TestIntroOpts.txt

Specify your database and device options as required.


Next Steps

Automated Regression Testing

best to set things up so that you automatically

  • build,
  • load binaries on the hardware,
  • start target running,
  • run Stride tests
  • publish results to test space

Organizing Tests

put test results in suites

develop tests with namespace conventions

Publication of Test Results

Upload to test space

comparison with previously uploaded data

immediately see trends in

  • number of tests in each suite and overall

Best Practices

Use C++ Test Classes if Possible

If possible, use C++ Test Classes to write your test units. Test Classes offer extra features and are the easiest to use for programmers.

Use Namespacing to Organize Tests

Over time, you will end up with lots of test units. Grouping these tests for display or running will become important as the count of test units grows. (You can see an example of C namespacing in the TestIntro tests.)