Studio:Scripting Overview: Difference between revisions
No edit summary |
No edit summary |
||
Line 8: | Line 8: | ||
STRIDE makes it possible to use scripts written in either JScript or Perl | STRIDE makes it possible to use scripts written in either <ref>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 drive the testing of a unit or units by setting parameter values, calling functions, and receiving return values (or sending/receiving messages) |
Revision as of 17:43, 3 March 2008
The Role of Scripting in STRIDE
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