Training Tests in Script: Difference between revisions
(Created page with '== Background == == What is an expectation test ? == == Why would I want to write one in script ? == == Sample: Expectations == === Build the test app === === Sample Source:…') |
No edit summary |
||
| Line 1: | Line 1: | ||
== Background == | == Background == | ||
The STRIDE Framework allows you to write expectation tests that run on the host while connected to a running device that has been instrumented with [[Test Point|STRIDE Test Points]]. Host-based expectation tests leverage the power of scripting languages (perl is currently supported, others are expected in the future) to quickly and easily write validation logic for the test points on your system. What's more, since the test logic is implemented and executed on the host, your device software does not have to be rebuilt when you want to create new test or change existing ones. | |||
Please review the following reference articles before proceeding: | |||
* [[Test Modules Overview|Scripting Overview]] | |||
* [[Perl Script APIs|perl Test Modules]] | |||
== What is an expectation test ? == | == What is an expectation test ? == | ||
An expectation test is a test that validates behavior by verifying the occurrence (or non-occurrence) of specific test points on your running device. The STRIDE Framework makes it easy to define expectation tests via a single setup API to define a test ([[Perl_Script_APIs#Methods|see TestPointSetup]]) . Once defined, expectation tests are executed by invoking a ''wait'' method that evaluates the test points on the device as they occur. The wait method typically blocks until the entire defined expectation set has been satisfied '''or''' until an optional timeout has been exceeded. | |||
== How to I start my target processing scenario ? == | |||
It's often necessary, as part of test, to start the processing on the device that causes the test scenario to occur. Sometimes processing is invoked via external stimulus (e.g. send a command to a serial port or send a network message). Given the [http://search.cpan.org/ wealth of libraries] available for perl, it's likely that you'll be able to find modules to help you in automating common communication protocols. | |||
If, on the other hand, the processing can be invoked by code paths in your application, you can consider using [[Function_Capturing|function fixturing]] via STRIDE. STRIDE function remoting allows you to specify a set of functions on the device that are to made available in the host scripting environment for remote execution. This can be a convenient way to expose device application hooks to the host scripting environment. | |||
Whatever the approach, we strongly encourage test authors to find ways to minimize the amount of manual interaction required to execute expectation tests. Wherever possible, we encourage you to try to find ways to fully automate the interaction required to execute your expectation scenarios. Fully automated tests are more likely to be run regularly and therefore provide a tighter feedback loop for your software quality. | |||
== Why would I want to write one in script ? == | == Why would I want to write one in script ? == | ||
TBD or remove. | |||
== Sample: Expectations == | == Sample: Expectations == | ||
Revision as of 22:16, 13 May 2010
Background
The STRIDE Framework allows you to write expectation tests that run on the host while connected to a running device that has been instrumented with STRIDE Test Points. Host-based expectation tests leverage the power of scripting languages (perl is currently supported, others are expected in the future) to quickly and easily write validation logic for the test points on your system. What's more, since the test logic is implemented and executed on the host, your device software does not have to be rebuilt when you want to create new test or change existing ones.
Please review the following reference articles before proceeding:
What is an expectation test ?
An expectation test is a test that validates behavior by verifying the occurrence (or non-occurrence) of specific test points on your running device. The STRIDE Framework makes it easy to define expectation tests via a single setup API to define a test (see TestPointSetup) . Once defined, expectation tests are executed by invoking a wait method that evaluates the test points on the device as they occur. The wait method typically blocks until the entire defined expectation set has been satisfied or until an optional timeout has been exceeded.
How to I start my target processing scenario ?
It's often necessary, as part of test, to start the processing on the device that causes the test scenario to occur. Sometimes processing is invoked via external stimulus (e.g. send a command to a serial port or send a network message). Given the wealth of libraries available for perl, it's likely that you'll be able to find modules to help you in automating common communication protocols.
If, on the other hand, the processing can be invoked by code paths in your application, you can consider using function fixturing via STRIDE. STRIDE function remoting allows you to specify a set of functions on the device that are to made available in the host scripting environment for remote execution. This can be a convenient way to expose device application hooks to the host scripting environment.
Whatever the approach, we strongly encourage test authors to find ways to minimize the amount of manual interaction required to execute expectation tests. Wherever possible, we encourage you to try to find ways to fully automate the interaction required to execute your expectation scenarios. Fully automated tests are more likely to be run regularly and therefore provide a tighter feedback loop for your software quality.
Why would I want to write one in script ?
TBD or remove.