An approach to apply the Separation of Concern Principle in UI Test Automation !

At the beginning let’s emphasize that the automation is kind of engineering and these activities/goals are the core of the software industry aspects. Basically, I’m not a quality engineer but ensuring the quality has my attention. I’ve been having a curiosity for this field in last years then I had this chance with last project witch is a desktop application.

We have built an automation infrastructure that is fragmented into four contexts:

The arrows demonstrate the direction of the dependency.

1. Application

Is responsible for launching the app with the configured values, resolving the inspection 3rd party library and initializing a session with the app. It has an entry point for the nested views. It talks mostly technical language and few business language.

2. Views

It defines the views and it’s UI elements hierarchically, so each element has an owner and is composed in a parent element. It exposes the business actions and actual results. Also it is responsible for loading the UI structure from Json files. It talks mostly business language and a few technical languages.

For any reason if a certain element or view has been moved to another module all what we need is to edit it’s meta data to point to the new parent.

3. Tests

It has the business scenarios/assertions of the test cases. It talks only business language.

4. Inspector

This is for inspecting the UI elements by any type. When we want to locate a specific element relative to another element or we want to inspect an operational data i.e., items in a grid, we do that using programmatic / dynamic inspection.

To achieve that it exposes a parametrized functionality that is needed to manipulate the UI. In our case we wrap the usage of xpath, page-source parsing, get child elements “/*”, or get input elements by it’s label ”/following-sibling:”.

Each time the inspector is locating an element he does that hierarchically based on the view’s meta-data.

This context talks only in technical language.

The Design

The infrastructure is implemented based on OOP concepts i.e. composition, abstraction/polymorphism. .The following diagram demonstrates the relationship between the four contexts.

Hypothetically, the AppiumInspector is pluggable. As we see, the Inspector domain is totally hidden from Tests.

The abstraction layer is for common behavior or definitions to governance the concrete implementations.

The main window is composed in the App, it exposes a navigation functionality for the nested views. Also it is responsible for handling the popups and any raised window during the automation.

UI Metadata file specifies the UI structure, the inspection type (i.e. AutomationId, XPath, Name, Class or Type)

Technology Stack: Appium, C#, NUnit

Conclusion

This fragmentation and the abstraction helped us at the end to write a reliable script that is pure talks a business language and so close to the manual test cases steps.