Studio:Scripting Overview: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=The Role of Scripting in STRIDE= | =The Role of Scripting in STRIDE Studio= | ||
Scripting (running programs implemented in a supported scripting language) is fundamental to performing tests within STRIDE Studio. | |||
Scripts are used for the following tasks: | |||
* Manipulating/controlling Stride STUDIO | |||
* Driving tests | |||
* Simulating missing software units | |||
* Controlling the content of reports and their generation | |||
STRIDE extends the intrinsic capabilities of a scripting language by providing a set of COM Automation compatible objects and injecting an instance of each into your running script. | |||
{| class="wikitable" border="1" | |||
|+ Object instances that are injected into STRIDE Studio scripts | |||
! Injected Object !! Perl Variable Name !! JScript Variable Name | |||
|- | |||
| '''studio''' || <code>$main::studio</code> || <code>studio</code> | |||
|- | |||
| '''ascript''' || <code>$main::ascript</code> || <code>ascript</code> | |||
|- | |||
| '''testSuite''' || <code>$main::testSuite</code> || <code>testSuite</code> | |||
|- | |||
| '''reporter''' || <code>$main::reporter</code> || <code>reporter</code> | |||
|} | |||
=Controling STRIDE Studio from a Script= | |||
=Reporting from a Script= | |||
=Driving Tests from a Script= | |||
Scripts are the fundamental technique used for driving tests running in STRIDE Studio. | |||
Using scripts to drive test scenarios or to simulate missing components has traditionally been difficult, if not impossible, when the unit under test is located on the target platform. Moreover, scripting languages and the C language do not necessarily mix well. There are data type mismatches, etc. *** Because of these difficulties, developers rarely use scripts for testing and integration, despite the potential benefits. | Using scripts to drive test scenarios or to simulate missing components has traditionally been difficult, if not impossible, when the unit under test is located on the target platform. Moreover, scripting languages and the C language do not necessarily mix well. There are data type mismatches, etc. *** Because of these difficulties, developers rarely use scripts for testing and integration, despite the potential benefits. | ||
| Line 7: | Line 36: | ||
* Wide spectrum of personnel are able to write scripts | * Wide spectrum of personnel are able to write scripts | ||
STRIDE makes it possible to use scripts written in either <ref name="ScriptCompat">JScript or Perl</ref>, to test your software units regardless of whether they are located on the host, target, or both. There are two common use cases for using scripts to integrate and test: | |||
* To drive the testing of a unit or units by setting parameter values, calling functions, and receiving return values (or sending/receiving messages) | |||
* | |||
* | * To mock (simulate) a missing function or other component so an interdependent unit can be tested. | ||
To illustrate these two use cases, consider a hypothetical embedded | To illustrate these two use cases, consider a hypothetical embedded | ||
| Line 30: | Line 58: | ||
Case #2) while the other drives the testing of function B (Use Case #1). | Case #2) while the other drives the testing of function B (Use Case #1). | ||
[[Image:Overview Scripting.png]] | |||
[[Image: | |||
As implied in the diagram, the fact that scripts replace functions A | As implied in the diagram, the fact that scripts replace functions A | ||
| Line 46: | Line 72: | ||
C are running on the host. | C are running on the host. | ||
<references/> | <div class="references-small"><references /></div> | ||
[[Category:Scripting]] | [[Category:Scripting]] | ||
Revision as of 18:42, 3 March 2008
The Role of Scripting in STRIDE Studio
Scripting (running programs implemented in a supported scripting language) is fundamental to performing tests within STRIDE Studio.
Scripts are used for the following tasks:
- Manipulating/controlling Stride STUDIO
- Driving tests
- Simulating missing software units
- Controlling the content of reports and their generation
STRIDE extends the intrinsic capabilities of a scripting language by providing a set of COM Automation compatible objects and injecting an instance of each into your running script.
| Injected Object | Perl Variable Name | JScript Variable Name |
|---|---|---|
| studio | $main::studio |
studio
|
| ascript | $main::ascript |
ascript
|
| testSuite | $main::testSuite |
testSuite
|
| reporter | $main::reporter |
reporter
|
Controling STRIDE Studio from a Script
Reporting from a Script
Driving Tests from a Script
Scripts are the fundamental technique used for driving tests running in STRIDE Studio. Using scripts to drive test scenarios or to simulate missing components has traditionally been difficult, if not impossible, when the unit under test is located on the target platform. Moreover, scripting languages and the C language do not necessarily mix well. There are data type mismatches, etc. *** Because of these difficulties, developers rarely use scripts for testing and integration, despite the potential benefits.
- You don't have to recompile your target when test changes are made in the script
- Scripting is very flexible
- Wide spectrum of personnel are able to write scripts
STRIDE makes it possible to use scripts written in either [1], to test your software units regardless of whether they are located on the host, target, or both. There are two common use cases for using scripts to integrate and test:
- To drive the testing of a unit or units by setting parameter values, calling functions, and receiving return values (or sending/receiving messages)
- To mock (simulate) a missing function or other component so an interdependent unit can be tested.
To illustrate these two use cases, consider a hypothetical embedded
application containing three functions: A, B, and C. A calls B and B calls
C as shown on the left in the diagram below. Suppose that you developed
function B and you are ready to test it, but function C is not yet completed.
One solution, which would allow you to continue testing regardless of
the availability of function C, is to use scripts as shown on the right
in the diagram below. One script simulates the missing function C (Use
Case #2) while the other drives the testing of function B (Use Case #1).
As implied in the diagram, the fact that scripts replace functions A
and C does not change the interfaces with function B; via STRIDE, interfaces
defined in your embedded application are available at the source level
in your favorite scripting language. In addition, function B could be
on the target application, whereas the scripts replacing functions A and
C are running on the host.
- ↑ JScript or Perl