Layered Framework Architecture
Principle:
The architecture of the test framework is layered and consists of 3 horizontal layers and one vertical.
Horizontal layers:
Vertical layer:
These layers of abstraction in the architecture separate responsibilities, give flexibility to the framework and greatly reduce the maintenance and refactoring effort.
As long as we create implementation-agnostic interfaces between the different layers, the underlying implementation of each one can be completely overhauled without impacting the others.
This gives us the flexibility to, for example, swap out the 3rd party automation tool with a completely different one or something that was developed in-house with relative ease.
It also means that, in case of a significant change in UI of the SUT (system-under-test), we'd only have to refactor the UI Map sublayer while the business logic of the test scripts can remain untouched.
Initially, designing the framework in these different layers might seem like too large of a development effort.
However, it is often the absence of a proper layered architecture that results in the stereotypically hard to maintain automated GUI test suite that gets abandoned in the midst of an ongoing project.
It might sometimes tempting to break the insulation between these layers over the course of a project yet developers should refrain from doing so as it will greatly increase the maintenance effort of the test suite over time.
Investing development effort in keeping these layers properly separated will pay off in the long term.