Solving: How to write good UI interaction tests? #GivenWhenThenWithStyle

Last week, you voted on options for fixing a broken user-interface interaction test.

We’re very glad to have a guest expert this week. Andy Knight, blogging as Automation Panda, took the challenge on and provided a comprehensive answer on his blog.

The community had some great ideas as well this week. Here are some of the best responses.

Ken Pugh suggested to “Think in terms of user functionality, not specific clicks”, and abstracting away individual user interface actions that could be then implemented using step definitions. He provided an example of how that could look.

Gaspar Nagy proposed something similar, particularly looking at the causes of the risks that the tests are supposed to be protecting against:

I definitely would dig deeper into that risk. The risk is in the UI integrations, but in what nature?

A: Is it that fragileness of the UI interaction solution causes our users to not be able to get the business value (e.g. they cannot register, because of a js glitch). In this case I would use (some) business-language scenarios and automate them through the UI (or to the UI as well). But other non-BDD tests, like UI smoke tests or approval tests would work also fine.

B: If the risk is if we understood the UI interaction properly and whether our solution solves the right expectation (E.g. the validation of the new user name happens instantly even before submitting the registration form.), then UI interaction terms can sneak into the scenario. But even in this case I would try to focus on the UI concepts, not the individual HTML elements, so I would say “When I provide my user name as ‘foobar’” instead of “When I type ‘foobar’ into the text box ‘tbUserName’”.

Christian Quirós proposed “You re-write the specification layer (feature file) to avoid implementation details and to describe the system behavior instead, then, you have multiple implementations of the automation layer.” He suggested applying Hexagonal Architecture, a pattern to isolate the business domain and provide abstractions for interactions, where a feature file can be “driving the application through the UI by using another step definition implementation”. This is an excellent approach for situations when we want to hide UI details from the specification but still execute tests through the UI. Christian also proposed applying the Screen Play pattern to restructure the user interactions in terms of required behaviours.

Come back next week for a new challenge!