On The Road To Abstraction

On The Road To Abstraction

Selenium has contributed over many years a tremendous effort to make test automation mainstream accepted practice nowadays. I find the technique of being able to duplicate a typical (experienced) user session of a software product, making some assertions about correctness during the session, and the ability to replay the recording thus produced and to provide a report on the test result, is the greatest benefit of test automation one could get.

It was possible to do this in the older version of Selenium. Unfortunately, there is no recorder in Selenium WebDriver 3, so it is no longer possible for a single person to create a large set of automated tests in reasonable time. Another problem that is actually already solved by several Open Source solutions is to move away from very low-level browser actions (press a button, click something). It makes one (at least myself) feel nauseous and having to go to the toilet for relief.

So, a higher abstraction layer above the necessary basic WebDriver 3 one is a welcome future enhancement. And, there can be more than one layer, leading to better-to-read Python code. The final layer should be the ultimate one. It should be so easy to read, that a high school student can somewhat “get it”. The aim: user story-like test scenarios in English. And with Germanium, and an extra third-party layer above it, you can achieve this!!! In fact, my previous blog provided exhaustive details of implementing AbstractSelectors. The ultimate layer part is missing.

We can only partially achieve the ultimate abstraction of a user test case (or story) with Germanium strictly alone as a layer above the WD 3 one. That is provided by the AbstractSelector class that can be used at will to provide at least well-named and suggestive selectors, when these are implemented as concrete selectors in the Germanium code. But, you must read the Germanium code you write in the supported programming languages.

BEHAVE is an existing Python automation framework providing an easy to understand syntax for a test scenario. Behave thus provides another abstract layer above the previous "selenese" ones. It allows us a DSL. And it is the ultimate solution for abstraction in a human language. So, placing Behave above the Germanium layer, we can formulate the following English description, which we could call a domain specific language variant, or if you like, a user scenario automated test:

Given in the browser <browser>
When I go to the url <url>
And I go into section <section> using document composer <composer>
And I insert the block <block>
Then the document content has <content>

Notice that at minimum, an automated test issues commands to a browser and can make assertions on the results for validity of the web app SUT. We have ALL the above, right now, available, working, and tested. What’s more, you can achieve end-to-end automated testing to cover a lot more SUT execution with far less front-end UI test automation. It’s work, but worthwhile.

Page Objects bind the SUT too much to the automated test. The test starts looking like the web application. I don’t find this useful as I want test automation independence from the application being tested. I am thinking about alternatives to the PO Pattern, for example AVT (automated visual testing, with partial snapshots and image comparison assertions to base snapshots). I believe W3C is too. But, my architect is not yet convinced, so no promises.

Well, in my next post, I’ll show you Behave combined with Germanium code examples, based on the material of my first post.

Quiz on general principles: why is a JUNIT or NUNIT test that uses garbage input for strings useless? My answer: use the input fields in the front-end UI for this purpose. Let it go end-to-end.

 

Article Photo taken from Pexels: https://www.pexels.com/photo/road-landscape-nature-forest-39811/