Archives

Tag: bdd

Gwen-web was designed to take the development pain out of web automation and make it easier to achieve with all types of web applications regardless of the underlying technologies or frameworks they were built with. Our goal was to make Gwen work consistently with web pages built on any kind of server or client side framework. All web pages are just HTML documents when they hit the browser after all. But this HTML is not always static and with the recent trend of modern JavaScript framework adoption, web pages are getting more and more dynamic. A lot more things happen in web pages nowadays. Lots of JavaScript code gets loaded and all types of browser events trigger functions and Ajax requests at various times resulting in all sorts of dynamic and asynchronous rendering that makes for a very rich user experience. This might make things more pleasant for human users but it is often a hard challenge for automation programs (or robots).

The Evaluation Test

So I thought I’d try Gwen out on some web pages built on the popular and modern JS frameworks of today to see how well it performs. To do this, I wrote a feature suite that mimics these Serenity tests and ran it over the various JS implementations of the publicly available TodoMVC web application (this is a project which offers the same Todo web application implemented on different JavaScript frameworks).

It is important to note that Gwen uses the Java implementation of the Selenium web driver and is not a JS framework itself but rather a Java executable that reads plain text Gherkin features and dynamically interprets them into automated web page interactions. The evaluation performed here provides us with an indication of how well Gwen interacts with web applications built on different types of JS frameworks.

The Evaluation Results

The suite consists of 26 scenarios which I ran over 33 different JS implementations of the Todo app (for a total of 858 scenarios). I ran it in a Chrome browser on a Mac. It took about 50 minutes to run every scenario in sequence. I also ran the tests in parallel (on a dual CPU quad core machine) which took about half the time and produced consistent results. Gwen was executed with the gwen.feature.failfast setting overriden to false to force all scenarios in a feature to execute even if one or more prior ones fail.

94% of Scenarios Passed :)

All tests completed successfully and passed for the following frameworks.

JavaScript:

Backbone.js

AngularJS

Ember.js

KnockoutJS

Dojo

Knockback.js

CanJS

Polymer

React

Mithril

Ampersand

Vue.js

Marionette.js

Vanilla JS

Vanilla ES6

jQuery

Compile-to-JS:

Spine

Dart

GWT

TypeScript + Backbone.js

TypeScript + AngularJS

TypeScript + React

Serenade.js

Reagent

Scala.js + React

Scala.js + Binding.scala

js_of_ocaml

Humble + GopherJS

6% of Scenarios Failed

Some tests failed for the following frameworks. I have not investigated these in detail but have included my initial findings below.

JavaScript:

Flight

15 scenarios failed, 11 passed

Intermittent element hits and misses

Entered data leaks or is lost

TroopJS + RequireJS

15 scenarios failed, 11 passed

Unresponsive to enter key being sent to field

Compile-to-JS:

Closure

5 scenarios failed, 21 passed

Unresponsive to checkbox being clicked

Elm

8 scenarios failed, 18 passed

Intermittently not sending some characters to field

AngularDart

3 scenarios failed, 23 passed

Intermittently not rendering conditionally visible buttons

Conclusion

Gwen interacted successfully with a large majority of the popular JS implementations. All tests passed for 28 of the 33 implementations evaluated. More than 94% of all scenarios passed in total.

Try it Yourself

All the todoMVC features used in this evaluation are also bundled in the gwen-web distribution as of release 2.3.3. If you install the latest gwen-web distribution, you can run it by calling the following command in the directory where you install Gwen (to run in parallel mode, just add the --parallel switch):

Standard Execution

The following example shows a meta file that defines a step definition for joining two strings together and a feature file containing a scenario outline that exercises it with different string values.

Meta file:

Feature: Join Strings Meta
@StepDef
Scenario: I join the two strings
Given the result is "${string 1}${string 2}"

Feature file:

Feature: Join Strings
Scenario Outline: Joining <string 1> and <string 2> should yield <result>
This scenario is evaluated at the point where the outline is declared.
Joining <string 1> and <string 2> should yield <result>
Given string 1 is "<string 1>"
And string 2 is "<string 2>"
When I join the two strings
Then the result should be "<result>"
Examples: Basic string concatenation
The header row contains the placeholder names. The body rows that
follow contain the data that is bound to each scenario that is evaluated.
| string 1 | string 2 | result |
| howdy | doo | howdydoo |
| any | thing | anything |

The Gwen interpreter will expand and evaluate each record in the body of the Examples table at the point where the scenario outline is declared in the feature. This example contains just one Examples clause in the outline but many can be specified.

Evaluated scenario outlines appear in HTML reports as follows.

Each Examples table record in the report (excluding the header) is rendered as a hyperlink that when hovered over and clicked will reveal the expanded scenario.

Outlines as StepDefs for Deferred Execution

For cases where you may want to reuse a scenario outline across many scenarios or features, you can make it a step definition in the meta and then call it by name in the feature where you want it to execute.

Meta file:

Feature: Join Strings Meta
@StepDef
Scenario: I join the two strings
Given the result is "${string 1}${string 2}"
@StepDef
Scenario Outline: Joining <string 1> and <string 2> should yield <result>
This outline is loaded into memory and execution is deferred until a call is made.
Joining <string 1> and <string 2> should yield <result>
Given string 1 is "<string 1>"
And string 2 is "<string 2>"
When I join the two strings
Then the result should be "<result>"
Examples: Basic string concatenation
The header row contains the placeholder names. The body rows that
follow contain the data that is bound to each scenario that is evaluated.
| string 1 | string 2 | result |
| howdy | doo | howdydoo |
| any | thing | anything |

Feature file:

Feature: Join Strings
Scenario: Join different pairs of strings and compare their results
Given Joining <string 1> and <string 2> should yield <result>

The Gwen interpreter will load the outline in the meta to memory and execute it when it is called by the scenario in the feature. Any number of scenarios in any features can call the outline in this way as long as the meta is in scope.

Calls to scenario outlines are rendered as steps in HTML reports (just like all calls to step definitions are).

When the step is hovered over and clicked, the called outline is revealed as a StepDef.

Each Examples table record in the report (excluding the header) is rendered as a hyperlink that when hovered over and clicked will reveal the expanded scenario.

Notes about outlines as StepDefs

They are reusable

They can be called from anywhere, including backgrounds and the REPL console too!

If the name of the outline contains data placeholders, then their bound table values are substituted into the expanded scenario name prefixes at evaluation time. Specifying placeholders in the name is handy in this way but it is also optional. We could have named the outline ‘joining two strings should yield a compound string‘ instead and called it by that name if we wanted to. In this case the expanded scenarios would all have this same name prefix. Either way, the expanded scenarios will always be given unique names that are suffixed with the example record number (see report snapshots above). If you are using placeholders in the name though, then your call to the step definition should also include the same placeholder name literals (as shown in this example) to prevent potential name clashes with any other step definitions you may have with a similar name. If a name clash does occur, Gwen will report it and you will need to rename.

Like this:

Gwen 2 has been released with the latest technologies including Java 8 and Selenium WebDriver 3. All binary dependencies have also been updated and the project is now built using Scala 2.12.

There is one impact to Firefox users but nothing else has changed. With the upgrade to Selenium 3, all browser vendors (including Mozilla) are responsible for developing and providing the native drivers for their own browsers. To use Firefox, you will now need to download a native Firefox driver and set the following in your gwen.properties file:

Page Objects

I recently discovered a Page Objects Refactored article which suggests that ‘flaky’ web tests are often misattributed to Selenium web driver issues and that the problem instead is poorly coded page objects that were not written with solid OO principles in mind. Programming languages allow programmers to achieve the same or similar results in more than one way. For this reason, design patterns were introduced to help developers implement known solutions to known problems. But even design patterns require discipline and cannot be strictly enforced to any useful degree without introducing a specialised framework. Frameworks also are geared at software developers and not software users.

What is needed is a pre-programmed automation tool that frees users from development concerns.

No Page Objects

One of the primary goals of the gwen-web project is to give users a tool for automating web pages without needing to develop any page objects or compile any code. Gwen-web is an interpreter that accepts plain text Gherkin features as input and produces executing web driver instructions as output. All interactions with the web driver API happen in a precompiled and embedded web engine through a prescribed DSL. This web engine also handles many of the known gotchas and pitfalls that programmers typically face when working directly with the web driver. Users also have the flexibility to compose custom DSLs (their own step definitions) which are also expressed in Gherkin. With this approach, developing page objects and adopting design patterns is no longer required. Furthermore, programmer errors are eliminated and ‘flakiness’ is removed. The ability to compose specifications in plain Gherkin text is all that is necessary.

An example

Consider the following Gherkin feature:

Feature: Google search
Scenario: Perform a google search
Given I do a google search for "gwen-web"
When I click the first result
Then the page title should contain "gwen-interpreter/gwen-web"
And the current URL should be "https://github.com/gwen-interpreter/gwen-web"

With Gwen, we can take a plain text feature like this one and execute it “as is”.

If you install gwen-web, you will find the above feature file located at features\google\GoogleSearch.feature relative to your root install directory (the location where you unpacked the distribution). If you open a command prompt to this location, you can execute this feature as follows:

On Windows:

gwen -b features\google\GoogleSearch.feature

On a Mac:

./gwen -b features/google/GoogleSearch.feature

When this is launched, gwen-web will:

Open a new browser session

Navigate to the google home page

Submit a Google search

Click the first result that comes back

Verify that the title of the resulting page contains some expected text

Check the URL of the resulting page

How does it work?

Alongside the GoogleSearch.feature file, you will also find a Google.meta file. This file is also a Gherkin feature file, but with a .meta file extension. It defines the step definition for the first step in our feature. The remaining steps are all predefined in the web engine. We don’t need to define step definitions for those since the web engine already knows how to execute them.

Here are the contents of the Google.meta file (minus the comments):

Feature: Google search
@StepDef
Scenario: I do a google search for "<query>"
Given I navigate to "http://www.google.com"
And the search field can be located by name "q"
When I enter "$<query>" in the search field
Then the page title should start with "$<query>"
And the first match can be located by class name "r"
And the first result can be located by tag name "a" in the first match

This meta defines an annotated scenario named: I do a google search for "<query>". This is how you define a step definition with Gwen. It’s simply just a @StepDef annotated scenario that in this case accepts a <query> string as a parameter followed by a sequence of steps that define its operations. When this meta file is processed by Gwen, the step definition is loaded and made available to any executing feature that is passed in. In our example, Gwen automatically discovers this meta file (because it is in the same directory as the feature itself) and preloads the step definition defined in it to memory. When the first step in our feature executes, Gwen matches it to the step definition by name and binds the passed in “gwen-web” string literal to the <query> parameter which is then used by the steps therein to perform the Google search.

Comparing the feature step with the step definition reveals the match that Gwen is able to detect:

I do a google search for "gwen-web"
I do a google search for "<query>"

Another example

Feature: Complete a Todo
Background: Open a new browser
Given I start a browser for James
Scenario: I should be able to complete a todo
Given I browse to the application home page
When I add a "Walk the dog" item
And I add a "Put out the garbage" item
And I complete the "Walk the dog" item
Then the "Walk the dog" item should be completed
Scenario: I should see the number of todos decrease when an item is completed
Given I browse to the application home page
When I add a "Walk the dog" item
And I add a "Put out the garbage" item
And I complete the "Put out the garbage" item
Then the number of items left should be "1"

And make it executable with a meta specification like this:

features\todo\Todo.meta

Feature: Todo meta
@StepDef
Scenario: I browse to the application home page
Given I navigate to "http://todomvc.com/examples/angularjs/#/"
Then the todo field can be located by id "new-todo"
And the number of items left can be located by javascript "document.getElementById('todo-count').children[0]"
And I locate the todo field
@StepDef
Scenario: I add a "<todo>" item
Given I enter "$<todo>" in the todo field
And the "$<todo>" item can be located by xpath "//*[@class='view' and contains(.,'$<todo>')]//label"
And the "$<todo>" item checkbox can be located by xpath "//*[@class='view' and contains(.,'$<todo>')]//input[@type='checkbox']"
@StepDef
Scenario: I complete the "<todo>" item
Given I click the "$<todo>" item checkbox
@StepDef
Scenario: the "<todo>" item should be completed
Given the "$<todo>" item checkbox should be checked

And then launch it like this (assuming you have created the above two files):

Windows:

gwen -b features\todo\CompleteATodo.feature

Mac:

./gwen -b features/todo/CompleteATodo.feature

Composable automation

With Gwen we don’t have to do any heavy development work. We only need to compose specifications.

Notice that all the technical automation glue (JavaScript expressions, XPath locators etc..) are confined to meta. The features themselves are clean, readable, self documenting, and easily understood. You could easily have a BA or tester write the feature files upfront and then have a developer plug in some meta behind it. Or you could have tech savvy testers with enough HTML and JavaScript skills to write the meta themselves. Teams can choose to be as declarative or as imperative as they like in how they write their features. Tailored meta can always be crafted to suit.

So there you have it ~ web automation with #NoPageObjects and no selenium coding!

If you would like to see a more detailed example, then see our Automation by Meta blog post. See also our Wiki and FAQ pages for more information about Gwen.