Studio:Scripting Test Units - Revision history

Timd at 00:37, 21 August 2009

2009-08-21T00:37:54Z

← Older revision		Revision as of 00:37, 21 August 2009
Line 69:		Line 69:

	[[Category:Studio:Scripting]]		[[Category:Studio:Scripting]]
	[[Category:Test Units]]		[[Category:Studio:Test Units]]

Timd: Text replace - 'Category:Scripting' to 'Category:Studio:Scripting'

2009-08-20T23:45:38Z

Text replace - 'Category:Scripting' to 'Category:Studio:Scripting'

← Older revision		Revision as of 23:45, 20 August 2009
Line 68:		Line 68:
	</source>		</source>

	[[Category:Scripting]]		[[Category:Studio:Scripting]]
	[[Category:Test Units]]		[[Category:Test Units]]

Timd: Scripting Test Units moved to Studio:Scripting Test Units

2009-08-18T22:11:28Z

Scripting Test Units moved to Studio:Scripting Test Units

← Older revision	Revision as of 22:11, 18 August 2009
(No difference)

Timd at 00:07, 29 May 2009

2009-05-29T00:07:03Z

← Older revision		Revision as of 00:07, 29 May 2009
Line 1:		Line 1:
	== Scripting a Test Unit ==		== Scripting a Test Unit ==
	In most [[Test Units\|Test Unit]] applications, a standard, S2-supplied host test runner is sufficient. However, for applications that require finer control, Test Units may be run from custom-written scripts.		In most [[Test Units\|Test Unit]] applications, a standard, S2-supplied host test runner is sufficient. However, for applications that require finer control, Test Units may be run from custom-written scripts.

			This capability is offered by the [[STRIDE Studio]] product.

	Custom scripts can be written by hand or automatically generated using the Script Wizard and a corresponding [[Templates\|template script]]. These scripts use the [[AutoScript]] (Ascript) COM object to access test metadata and features of the STRIDE Runtime. Specifically, the [[AutoScript#ascript.TestUnits\|AutoScript TestUnits]] collection is used to represent the currently-available [[Test Units]]. The collection comprises [[AutoScript#ascript.TestUnits.Item\|Ascript TestUnit]] objects which represent the individual Test Units.		Custom scripts can be written by hand or automatically generated using the Script Wizard and a corresponding [[Templates\|template script]]. These scripts use the [[AutoScript]] (Ascript) COM object to access test metadata and features of the STRIDE Runtime. Specifically, the [[AutoScript#ascript.TestUnits\|AutoScript TestUnits]] collection is used to represent the currently-available [[Test Units]]. The collection comprises [[AutoScript#ascript.TestUnits.Item\|Ascript TestUnit]] objects which represent the individual Test Units.

Timd at 18:52, 7 April 2009

2009-04-07T18:52:59Z

← Older revision		Revision as of 18:52, 7 April 2009
Line 67:		Line 67:

	[[Category:Scripting]]		[[Category:Scripting]]
	[[Category:~~TestUnits~~]]		[[Category:Test Units]]

Timd at 18:52, 7 April 2009

2009-04-07T18:52:30Z

← Older revision		Revision as of 18:52, 7 April 2009
Line 65:		Line 65:
	}		}
	</source>		</source>

			[[Category:Scripting]]
			[[Category:TestUnits]]

Timd: New page: == Scripting a Test Unit == In most Test Unit applications, a standard, S2-supplied host test runner is sufficient. However, for applications that require finer control, Tes...

2009-04-07T18:51:20Z

New page: == Scripting a Test Unit == In most Test Unit applications, a standard, S2-supplied host test runner is sufficient. However, for applications that require finer control, Tes...

New page

== Scripting a Test Unit ==
In most [[Test Units|Test Unit]] applications, a standard, S2-supplied host test runner is sufficient. However, for applications that require finer control, Test Units may be run from custom-written scripts.

Custom scripts can be written by hand or automatically generated using the Script Wizard and a corresponding [[Templates|template script]]. These scripts use the [[AutoScript]] (Ascript) COM object to access test metadata and features of the STRIDE Runtime. Specifically, the [[AutoScript#ascript.TestUnits|AutoScript TestUnits]] collection is used to represent the currently-available [[Test Units]]. The collection comprises [[AutoScript#ascript.TestUnits.Item|Ascript TestUnit]] objects which represent the individual Test Units.

Scripting your Test Unit runner gives you the following extra capabilities:

* You can pass values to C++ Class Test Unit constructors
* You can programmatically control which test units run and their order
* You can customize reporting options through the [[Reporter]] object

=== Single test unit example ===

The following example script is used to harness a test unit that has been captured using <tt>#pragma scl_test_class(Simple)</tt>.

'''JavaScript'''
<source lang=javascript>
var tu = ascript.TestUnits.Item("Simple");
// Ensure test unit exists
if (tu != null)
tu.Run();
</source>

'''Perl'''
<source lang=perl>
use strict;
use Win32::OLE;
Win32::OLE->Option(Warn => 3);

my $tu = $main::ascript->TestUnits->Item("Simple");
if (defined $tu) {
$tu->Run();
}
</source>

=== Multiple test units example ===

The following example script is used to harness two test units that have been captured using <tt>#pragma scl_test_class(Simple1)</tt> and <tt>#pragma scl_test_class(Simple2)</tt>.

'''JavaScript'''
<source lang=javascript>
var Units = ["Simple1","Simple2"];

// iterate through each function
for (i in Units)
{
var tu = ascript.TestUnits.Item(Units[i]);
if ( tu != null )
tu.Run();
}
</source>

'''Perl'''
<source lang=perl>
use strict;
use Win32::OLE;
Win32::OLE->Option(Warn => 3);

# initialize an array with all selected function names
my @UnitNames = ("Simple1","Simple2");
foreach (@UnitNames) {
my $tu = $main::ascript->TestUnits->Item($_->[1]);
die "TestUnit not found: $_->[1]\n" unless (defined $tu);
$tu->Run();
}
</source>