Verify is the key entry point into the verification system of TestPlan. This command tells the system that you are expecting to be in, or arrive at, a specific state→ within your system.

For example:

Verify Web.LoginForm

Indicates you are in the primary Web interface on the LoginForm. After calling Verify the current state of the system will be recorded as what was specified, in this case Web.LoginForm.

Refer to States→ for more information on state structure.

Verification Scripts

Verification scripts are intended to be inert: a verify script is composed of several checks and checkpoints but does not alter the state of the application.

The inert nature of a script cannot be verified by TestPlan, so you must adhere to this rule on your own.

Where

Verify scripts are to be located in a verify package accessible from one of the scriptDir's of TestPlan. The script name must match that of the state, with the exception that prefixed names are lowercased to produce package names.

For example for the command Verify Web.LoginForm TestPlan will look for a script called verify.web.LoginForm. If the script is not found it will simply be skipped.

When

The target verify script is called whenever a Verify command is executed. In addition to the target script the verify script of all parent states will also be called.

For example, say you wish to verify a failure condition on the LoginForm, thus you call Verify Web.LoginForm.Error. In turn TestPlan looks for these scripts:

• verify.web.loginform.Error
• verify.web.LoginForm
• verify.Web

This allows you to have common code to verify the LoginForm and specialized code in the Error state. Any common end of page checks could thus wise be done in the verify.Web script.

App.VerifyExpectNewWebPage

This context→ flag indicates whether a new page is expected. If true the verify script can do additional checks to ensure the new page is loaded correctly -- if need not to however.

If false it indicates the page is being verified again, or the page itself has not changed but some aspect of it.

This is intimately related to the Goto→ architecture. Goto→ will set this flag to true by default. The verification scripts are expect to then turn it off if they use it.

A normal script may call VerifyNewPage→ as a variance to Verify which simply sets the flag to true first.

Verify Script Feedback

In some situations the standard behaviour of the verification system does not quite match the requirements of the application. Therefore a feedback system is presented to allow individual verify scripts to communicate their wishes.

The feedback generally is done via the Verify context map. All of these settings take effect only after the current script has completed.

Verify:Stop

If Verify:Stop is set to true by a script then the hierarchy traversal will stop and verification will end.

Verify:Parent

Occasionally the state hierararchy will not map to an exact verification hierarchy. For example, from above, the Web.LoginForm.Error page may be a completely separate page to Web.LoginForm, thus traversing to this parent would not make sense.

The Verify:Parent thus specifies what is the correct parent state of the current one. In this example might say set %Verify:Parent% Web.

There is no limitation on what the parent may be, though it is intended to be an item higher in the hierarchy. If this is not the case perhaps the Verify:SameAs is more what is needed.

Verify:SameAs

This allows a state to indicate that it is actually a virtual state: something which exists in the logical state structure but not truly in the application system.

A common occurrence of this is when the submission of a form goes not to a notice page, but rather to a listing which now contains the saved item.

For example, we have a listing of widgets called Web.Login.Widget.List and a form to create new ones Web.Login.Widget.Form. When the user submits the form we go to the state Web.Login.Widget.Form.Save, however, in the application we simply go back to the form listing Web.Login.Widget.List. Our specific script may nonetheless check some success variable.

Check //span[@class='success']
set %Verify:SameAs% Web.Login.Widget.List

Using Verify:SameAs actually changes the current state. This is a vital difference to Verify:Parent. That is, in this example, if the user were to Verify Web.Login.Widget.Form.Save the current state after the call would be recognized as Web.Login.Widget.List.