Studio:Scripting Overview

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.

Object instances that are injected into STRIDE Studio scripts

Injected Object	Perl Variable Name	JScript Variable Name
studio	$main::studio	studio
ascript	$main::ascript	ascript
testSuite	$main::testSuite	testSuite
reporter	$main::reporter	reporter

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 , 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.