Test automation framework architecture. Part 2.2 - Two-layered architecture
As we've learned in previous posts of the series - Layered (also known as Tiered) architecture is a de-facto standard of the industry.
There're two major variations of this architectural pattern that one should be aware of: 3-layered architecture (described here) and 2-layered architecture. This post is going to concentrate on 2-layered architecture.
2-layered architecture is typically seen in UI-specific test automation frameworks. The key feature of this pattern is the absence of Business-layer, so most of the business-related logic are actually to be put into Page Objects.
In order to avoid "The God class" anti-pattern and still be able to contain business-related logic in Page Object, one usually uses libraries or frameworks that allow simplifying DOM-elements location, thus letting Page Objects to concentrate less on locating elements and more on business-logic itself.
The good thing in this architectural pattern is that it actually allows you to write less code (and let libraries to handle some complexity for you). The downside is obvious - you will have to learn and know those libraries you depend on. The downside may be overcome by actually creating universal DOM-location extensions yourself, but this may be a daunting task to do.
My personal preference is 3-layered architecture though, mostly because I am too lazy to learn new libraries. The other thing is that 3-layered architecture works the same way for any kind of products (Web UI, Desktop UI, Mobile, API, etc.)
On the other hand, those who are proficient in DOM-location libraries and frameworks (such as htmlelements) may gain significant speed-boost in they test-automation solution development.
Yet again it is one's conscious decision which approach to take, depending on the circumstances.
There're two major variations of this architectural pattern that one should be aware of: 3-layered architecture (described here) and 2-layered architecture. This post is going to concentrate on 2-layered architecture.
2-layered architecture is typically seen in UI-specific test automation frameworks. The key feature of this pattern is the absence of Business-layer, so most of the business-related logic are actually to be put into Page Objects.
In order to avoid "The God class" anti-pattern and still be able to contain business-related logic in Page Object, one usually uses libraries or frameworks that allow simplifying DOM-elements location, thus letting Page Objects to concentrate less on locating elements and more on business-logic itself.
The good thing in this architectural pattern is that it actually allows you to write less code (and let libraries to handle some complexity for you). The downside is obvious - you will have to learn and know those libraries you depend on. The downside may be overcome by actually creating universal DOM-location extensions yourself, but this may be a daunting task to do.
My personal preference is 3-layered architecture though, mostly because I am too lazy to learn new libraries. The other thing is that 3-layered architecture works the same way for any kind of products (Web UI, Desktop UI, Mobile, API, etc.)
On the other hand, those who are proficient in DOM-location libraries and frameworks (such as htmlelements) may gain significant speed-boost in they test-automation solution development.
Yet again it is one's conscious decision which approach to take, depending on the circumstances.
well explained
ReplyDelete