Test Plan Development

Edited on December 14, 2016

Test Plan concept

Test Plans define the order in which and the conditions under which Keywords and control structures are to be executed. They also store the directives which will feed keywords their input data and ensure that each step produces the expected result.

From a technical standpoint, Test Plans and Composite Keywords are identical. The distinctinction between the two is just a matter of type, which allows to factorize objects and better organize a project.

We define a Composite Keyword as a logical grouping of concrete Keywords which are often executed together and in a certain order. For example, one can build a composite keyword to represent a complete business case made up of a sequence of concrete Keywords. Then, the Test Plan will reference that Business Case (meaning, the corresponding Composite Keyword) along with other Keywords to simulate a large series of Business Cases, or maybe it will reference that same Composite Keyword multiple times but with different inputs and checks, for example in a ForEach loop, as a ways to "batch test" that Business Case.

We encourage you to make your Keywords as fine granular as possible and to move the logic to your Test Plans as much as possible to reduce the complexity of your project and your maintenance effort.

Test plan structure

A Test Plan is just a tree of objects. These objects can either be Keyword calls (also called Function Calls) or logical controllers, which are used to define when and how the different keywords are supposed to be executed.

When initially creating a Test Plan, you need to pick a logical controller as the root of your tree. By default, you can pick a Sequence for instance, which only ensures the order in which its children matches the order in which they're displayed in the Test Plan Editor.




On the right side of the editor, access is given to the two types of libraries : the control flow library (see tab "Controls") with the different logical controllers, and the Keyword library (see tab "Keywords) which displays by default the list of all Keyword found on the instance. You can search the Keyword list using the name field. You can add as many nodes as you want by clicking the + buttons of the controllers and keywords shown in the two libraries. They will then be added to the current node of the Test Plan Tree.

Then, using drag and drop and the upper arrow and lower arrow buttons, you can reorganize the nodes across their parents and place them in the order that you want.




Testplan example (ForEach)

// TODO : document pre-packaged Testplan example

Passing arguments to keywords

As shown in the demo keywords, passing arguments to keywords is easy. All you need to do is click the Keyword node in your tree and write your arguments into the "argument box" in the form of a json string. Everything else will be automatically filled out for you by default. We will see how to use the other fields in later sections.

Here for instance, we're setting the url "http://denkbar.io" as an argument with the key "url". STEP will make this input available to the underlying scripting engine at execution time.




The argument content can also be set dynamically via the use of groovy expressions. Here for instance, we're feeding the keyword with the value of an earlier variable. Notice the use of double brackets [[ ]] telling the pre-parser to interpret that part of the json string as a groovy expression, and hence allowing us to access any variable in the Test Plan.




Test plan execution

Once a Test Plan is correctly configured, it can be executed using the ► button. You will then be taken to the execution view which is covered in the section "Executing Tests".