After implementing the scripted code that
interacts with the target application, set up a stub action for the editor, and
create the action lines to set up and call the associated action.
Begin by opening TestArchitect Client, then expand the Car Rental
project of the TestArchitect explorer tree.
As in the
prior exercise, begin by creating a stub action in the TestArchitect client. Name it
check row count, and supply it with the
following arguments and data types:
Note that "Interface Entity" and "Interface Element"
have been specified as the data types for the window
and table arguments. This allows anyone entering the
check row count action in a test to have access to
these arguments' respective drop-down autocomplete lists.
Assuming you performed
the last exercise, you should have a test module named My scripted
tests. If not, go ahead and create it.
Add a new test case to test
module My scripted tests. Title this new test case
Test user-scripted action interacting with aut.
Optionally, add a test objective action beneath it,
referencing objective TO 01, since we're still testing
the Java harness (see below).
You will be testing your new action against the Car Rental application, so
go up to the INITIAL section and add a line to ensure that
your test uses the correct interface:
In your new test case, and an action line to invoke the action
with some real data:
Save your work.
This is all you need to properly call your
user-scripted action from the TestArchitect
client. In this particular invocation of the check row count
action, you are counting the number of rows of orders table
that have the value Ford Mustang Coupe
in their Car
column, with the expectation that the total will be 2. (If the
count is indeed 2, your action passes; if not, it fails.) The action is to be
performed on the View Orders
If, as above,
there are indeed 2 rows of the orders table
in which the
column holds Ford Mustang
, you can expect your test to pass.
You are now ready to try out your new action.