If you’ve followed the previous parts of this introductory guide, you’ve been able to create, deploy and execute a Keyword in step. Let’s now look at how you can leverage the platform to create a large scale scenario for functional or performance oriented purposes.

Pre-requisites

• You’ve completed local step installation guide
• You’ve completed your first execution in step
• You’ve completed Chrome automation guide

Creating a plan

Plans are a separate entity making use of Keywords. step provides a Plan editor which allows users to design automation scenarios in full isolation from Keyword implementations. Plans provide a wide array of pre-existing logical controllers usually referred to as Controls, which are a type of Artefact. Other Artefacts can be used to build Plans, one of the most important type being Keyword calls.

Let’s create a new plan: Go to the Plans tab of step’s top menu -> New Plan button -> Enter My First Plan in the Name field -> Save and Edit button.

Let’s create a simple Plan which will iterate through an array of JSON values and display them one by one. Add the ForEach Artefact from the Controls library in the right-hand pane of the editor.

Notice that a Plan structure is based on a tree. The order and relationship between the different nodes of the tree plays an important role so make sure to understand how they’re supposed to interact before adding them to your Plan. Documentation regarding each Control is provided under User guide.

The ForEach Control takes a source of data as a primary input. In this example, we will use the source type JSON String and pass a simple JSON document which can be iterated over. The document must represent of table of values with headers first, and then rows. Let’s use the following string as an example:

{ "pagename" :
    ["Consulting", "Products"],
  "url" : 
    ["https://www.exense.ch/solutions",
      "https://www.exense.ch/products"]}

Your Artefact’s configuration should now look like this:

Now let’s use the Echo Artefact along with some dynamic groovy code to display the contents of our JSON table. Add an Echo Control as a child of the ForEach node in your tree, toggle its groovy button (lightning icon) and set the following code in its input box:

"Page " + row.pagename + " can be accessed using the following url: " + row.url 

The Groovy language is used throughout step to resolve variables and perform simple technical operations. It is a convenient and flexible way to add dynamic behavior to a plan.

Your Echo node should now look like this:

If you execute the Plan (Play icon -> Environment TEST -> Play icon again), you should see the following result:

Note: make sure that you’ve checked the Groovy toggle button in your Echo artefact’s configuration, otherwise, the dynamic variables will be interpreted as static strings.

Passing input/output’s

In the guide My First Keyword we’ve hinted at the fact that Keywords can be used to receive and return data. Let’s see how we can leverage this to connect our Keyword with our newly created data source.

Let’s say we want our chrome driver to iterate over the urls provided by our data source. We’ll first have to change the code of our Keyword slightly in order to look for the url attribute. So let’s make the following change to our ChromeKeywords class:

	@Keyword
	public void createAndNavigate() {
	    System.setProperty("webdriver.chrome.driver",
	    		"D:\\MyInstalls\\chromedriver_win32\\chromedriver.exe");
	    ChromeDriver chrome = new ChromeDriver();
	    String homeUrl = input.getString("url");
	    chrome.navigate().to(homeUrl);
	    String extractedValue = chrome.findElement(By.xpath("//p[1]")).getText();
	    output.add("description", extractedValue);
	}

Notice that we’ve replaced the hard coded url with an access to the mother class’s input object via a key representing the input’s name and replaced our selenium instruction to return a description field from the webpage as an output of the keyword.

We will also make a small change to our JUnit test from the class ChromeKeywordsTest so that it can find the necessary input and display the description output when executing the Keyword locally:

	@Test
	public void createAndNavigateTest() throws Exception {
		ExecutionContext ctx = KeywordRunner.getExecutionContext(ChromeKeywords.class);
		Output<JsonObject> output = ctx.run("createAndNavigate", "{\"url\" : \"http://exense.ch/solutions\"}");
		System.out.println(output.getPayload());
	}

Let’s now save our source files, rebuild (Run As -> Goal: package -> *Run) and redeploy our Keyword by re-uploading the jar file into the configuration screen of our Keyword (Keywords menu entry -> Configure Keyword by clicking on the Wrench icon -> drag & drop your fresh uber jar into the Script field).

A popup will be displayed asking you if you want to update the existing resource, which will override all existing references throughout all Keywords potentially using the same file, or bind the new file as a new, distinct resource which will only apply to this Keyword.

Let’s now return to our Plan (Plans menu entry -> Edit Plan by clicking on the Pencil icon), delete the Echo Artefact and add a Keyword call from the Keywords sub-tab, in the right-hand pane of the Plan editor. After rebinding the input variable properly, your Plan should now look like this:

Validating outputs

One of the nice things about using outputs in step is that we can decouple the validation of certain property or fact about your application outside of the automation script. Let’s go back to our Plan and add an Assert Control to make sure that all descriptions start with the word “We”:

If we run this plan, the description outputs will be successfully matched against the Assert’s pattern and both Keyword executions will succeed.

If we now add another Assert to make sure that the word “product” is contained in every description,

as expected, one of these two steps will fail.

Using Sessions

We now have a relatively meaningful automation scenario with some amount of validation. However, as you can tell, each time an iteration commences, a new driver instance is started, which is highly inefficient in terms of resource management.

Let’s leverage step’s Session control in order to manage our chrome driver instances more elegantly. First, we’ll modify our Keyword code in order to register our chrome driver object into step’s session map. Just like the input and output objects, the session map is made accessible via the parent class (AbstractKeyword).

We’ll also split up our Keyword into three to better reflect the different phases of the browser’s lifecycle.

The resulting code will look like this.

• ChromeKeywords

	@Keyword
	public void createDriver() {
	    System.setProperty("webdriver.chrome.driver",
	    		"D:\\chromedriver_win32\\chromedriver.exe");
	    session.put("driver", new ChromeDriver());
	}
	@Keyword
	public void navigate() {
		ChromeDriver chrome = (ChromeDriver)session.get("driver");   
	    String homeUrl = input.getString("url");
	    chrome.navigate().to(homeUrl);
	    String extractedValue = chrome.findElement(By.xpath("//p[1]")).getText();
	    output.add("description", extractedValue);
	}
	@Keyword
	public void closeDriver() {
		ChromeDriver chrome = (ChromeDriver)session.get("driver");
		chrome.quit();
	}

• ChromeKeywordsTest

	@Test
	public void createAndNavigateTest() throws Exception {
		Output<JsonObject> output = null;
		ExecutionContext ctx = KeywordRunner.getExecutionContext(ChromeKeywords.class);
		ctx.run("createDriver", "{}");
		output = ctx.run("navigate", "{\"url\" : \"http://exense.ch/solutions\"}");
		ctx.run("closeDriver", "{}");
		System.out.println(output.getPayload());
	}

Again, the project will have to be re-packaged, and the jar re-uploaded into step. This time however, we will have to create 3 new Keywords each sharing the same jar resource in step.

After uploading the new version of your jar file, use the selector to pick the same existing resource for the two other keywords.

Note: it is important that each Keyword originating from the same jar be mapped to the same instance of the file as opposed to different copies. If you see multiple resource entries with an identical filename, you should clean up unnecessary entries and make sure afterwards that all Keywords are bound to the remaining resource.

Your selection screen should look like this:

If it is not the case, go to the right-hand drop-down list of the top menu, click the Resources entry, and delete unnecessary entries, then repeat the configuration process:

Once all three of your Keywords are created (as illustrated in the following screenshot),

go back to your plan, add a session object and reorganize your new Keywords as follows:

Note: don’t forget to pass the “url” input to the navigate Keyword call.

If you run the Plan now, you’ll find that your chrome instances properly shut down after execution.

Finally, let’s wrap our navigate call into a For loop artefact with 10 iterations:

You’ll now see that each browser instance will execute the navigate Keyword 10 times before shutting down, making more efficient use of the browser instances.

Check out the next section to see how executions can be scaled across an agent grid.