Hugh McCamphill
Hugh McCamphill's Blog

Hugh McCamphill's Blog

Test Automation Abstraction Quadrants

Test Automation Abstraction Quadrants

Hugh McCamphill's photo
Hugh McCamphill
·Feb 12, 2022·

4 min read

Recently I had the pleasure of doing a talk at the first VanRath meetup in Belfast. The event had a theme around getting testers into test automation (focusing on end-to-end automation).

I decided to look at this topic by showing how relatively easy it can be to get a basic test running but then also about what is required to create sustainable, maintainable, scalable test automation.

Getting started

There are a lot of frameworks that make getting started with test automation a lot easier than it used to be, such as WebdriverIO, Selenide or SeleniumBase. They generally take away a lot of the pain of getting set up, dealing with different drivers, wrapping lower-level Webdriver commands, and some patterns on how to write basic tests.

Having used some of them (in my case WebdriverIO and Selenide) they are great at doing this! I now no longer need to write the foundations for a new framework when joining a new project or company. However, regardless of whether using a lower-level API, or a higher-level one, they are necessary for driving the browser.

What's not necessary, but we typically benefit from if wishing to have strategic automation that scales, is to create abstractions in the language of the application, through something like Page Objects.

If we were to visualize these two sides (what's necessary and what helps writing maintainable test automation), we may have something like this

two_sides.jpg

What's useful to note here is that, typically, on the left, (Technical Facing), we should be looking to leverage solutions that already exist rather than invent our own solutions - it's likely a problem that has already been solved.

It's on the right (Application Facing), where you can develop rich, domain-specific languages, that model your own application and allow for the scalable maintainable automation mentioned earlier. This is the side of test automation that I think people can neglect, particularly if they are still coming to grips with the technical facing side of the automation.

Thankfully, over the last number of years, a number of frameworks and libraries in different languages have been developed that reduce the need to worry about the lower level technical aspects and should free people up to really think about how to model their application and create the abstractions that will make their test automation really work for them.

A test automation solution may incorporate more than this though.

  • On the technical side, in addition to what is necessary to drive the browser, we may have extra tooling and abstractions that enhance the framework.
  • On the application side, in addition to abstractions like page objects (that model the UI), we could have extra models for the data and for the domain.

new_quadrants.jpg

Top Left Quadrant - Necessary, Technical Facing

This is the necessary abstraction for driving the browser. We could write tests without any further abstractions, for example using the direct Webdriver bindings, but that is unlikely to lead to sustainable tests. We could also of course use a framework, such as those mentioned above, that build on top of Webdriver, but I would still consider this to be just the necessary, technical facing abstraction - we have yet to add abstractions relevant to the application under test.

Bottom Left Quadrant - Enhances, Technical Facing

These are the technical-facing abstractions that, while they aren't what directly drives your browser, act as enhancements to a test automation framework. In this space, you typically want to be leveraging existing libraries that provide these capabilities.

Top Right Quadrant - Creates a DSL, Domain Facing

These are the abstractions that people should typically mostly be concerned with - creating classes or functions that encapsulate some repeated behavior and then composing tests out of these. One example of these would be Page Objects, but of course, many others exist (for example, composing Page Objects into Business Objects). The main idea is that you are now in control of deciding how to model your application and create abstractions that will be readable, maintainable, scalable, and meaningful for your colleagues and your future self. This takes practice but will be the difference in making your test automation last in the long term.

Bottom Left Quadrant - Enhances, Domain Facing

Still, in the domain side of the model, we can have abstractions that help us in writing tests but are not directly about modeling the presentation of the application. Patterns that are typically useful here are factories and builders. By using these patterns, it becomes easy to generate domain objects, or the business concepts as code, that then further enhance the readability and maintainability of the test automation.

Final thoughts

Of course, all models are wrong, but do you find drawing the distinctions above useful? Is there anything else you would add?

Did you find this article valuable?

Support Hugh McCamphill by becoming a sponsor. Any amount is appreciated!

Learn more about Hashnode Sponsors
 
Share this