A state refers to a particular point in the program, or step in processing, along with all the current data in the program.

States play a vital role in software testing, defect tracking, and development of an application. They are the manner in which the concrete program is abstracted into a logical view of the system.

For a thorough overview of states refer to flowchart testing↗.

States in TestPlan

Within TestPlan states are maintained internally to track where in the application the operator is currently located. They are primarily used within the Verify→ and Goto→ systems.

For a suite of automated tests within a complex system it will be beneficial to give good consideration to the application states. This will allow effective use of TestPlan without needing to duplicate common testing code.

Example

Suppose we wish to model a few parts of an online forum. Before you can access the forum you need to login, and before that you need to register. There are two clear parts to the application, the logged in an not logged in status. This is how we establish our base states -- they are both web states so we'll call them Web.Login and simply Web for the non-login state.

Registration

This might be how a registration script would look like.

Goto Web.Register.Entry
SubmitForm with
  %Params% with
    %Name% %MyName%
    %Email% %MyEmail%
  end
end
Verify Web.Register.Confirm

GetEmail %MyEmail%
Verify Email.Registration

Goto→ will automatically call Verify→ on the resulting state. The hierarchy shown here will allow you to put elements common to both the registration form and the confirmation into a single verifications script verify.web.register. The verify.web.register.confirm could then look for specific success messages:

Check //p[@class='success']
#look for our email in a message
Check //blockquote[contains(text(),'%MyEmail%')]

You'll also notice we used an Email high-level state to provide verification scripts for the emails that are sent to us.