View Issue Details

IDProjectCategoryView StatusLast Update
0000213HTML[All Projects] Generalpublic2019-02-03 16:54
ReporterpvlasovAssigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000213: Using the action hierarchy abstraction for automated UI testing

The abstraction of representing system-human interface as a hierarchy of actions may be used not only for generating a Web user interface but also for testing is in the UI-independent way.
In this case UI tests will be written in terms of actions, not UI elements. Action hierarchies to be used by tests will be provided by "UI drivers" - libraries hiding UI actions such as button clicks and forms population
behind Action.execute() and other Action methods.
Low-level interaction can be achieved by adapting Action to Selenium WebDriver types.

Tests may be parameterized by device types, orientation, screen resolution - each permutation returning an action hierarchy backed by a driver with specified configuration.

Action drivers may pull metadata information from the system being tested and thus require little-to-no manual coding.

The action driver may capture screenshots and generate slideshows and videos. In this case tests may be used not only to test a piece of the UI functionality, but also to automatically produce educational
resource demonstrating how to use that piece of functionality (usage scenario, user journey).

Tests may be written in different ways, e.g. JUnit or BDD scripts, e.g. in Gherkin. One option is creation of application-specific DSL using Xtext and the action hierarchy specification. The base syntax of such DSL may be based on Gherkin and roles and steps will be application-specific
with steps being expressed in terms of actions, e.g.

As a bank customer
In order to manage my finances
I want to have access to current account transactions and balance.

Scenario 1: Browse current transactions
Given that I'm on the accounts summary page 
When I click on my account
Then I navigate to the account details page which displays account balance, which is equal to the account balance on the accounts summary page, and the current transactions (unbilled activity).

In the above example:

  • "bank customer" would be a user role defined in the language,
  • "accounts summary page" would be a UI state (action to be executed before the scenario can start).
  • "click on my account" would be an action available for execution in the current UI state.
  • "account details page" would be the end state.

The language/UI/action driver may hide the details on how to get to the initial state (e.g. log-in) and randomly use different options on getting to the initial state. Those options would correspond to already defined scenarios. A scenario in this case may be thought as a transition from a state A (action A) to state B (action B). Such transitions may be composed to. E.g. A -> B and B -> C may be composed to A -> C.

Recorded scenarios screenshots may be organized in a number of different ways:

  • By scenario referencing start and end state (action) documentation,
  • By the source state (action) - what can I do when I'm on the account summary screen?
  • By the target state (action) - what are the ways to do I get to the account details screen?

The documentation for recorded scenarios may be generated as a static web site or as a dynamic web application, perhaps with access control.

TagsNo tags attached.
Estimated effort


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2019-02-03 16:09 pvlasov New Issue
2019-02-03 16:17 pvlasov Summary Using an action hierarchy abstraction for automated UI testing => Using the action hierarchy abstraction for automated UI testing
2019-02-03 16:17 pvlasov Description Updated View Revisions
2019-02-03 16:54 pvlasov Description Updated View Revisions