About PageObjects
The “PageObjects“ are introduced mainly to avoid duplicated codes in test and simplify the maintenance works as well. PageObject just models the WebUI under test and represent the state transition among UI(page) activities.
PageObjects and Page Factory Pattern are terms from Selenium documents. The concepts of PageObject and (w/ or w/o) Page Factory are also derived from general OOD. It could be regarded as a much simplified ORM or a simple DAO if we regard test cases as data, test scenario pattern as DB tables. So the methodology can apply to other tests besides web.
- PageObject is a pattern of design
- Selenium Java package provides a basic support on lazy init. However, it is still a wheel to build for specific test area.
A rough mapping could describe the concept easilier:
| Traditional App Dev terms | Web Automation Test Concepts |
|---|---|
| DB drivers like mysql-connector | Web Drivers (take JSON call and get results from browser process) |
| DB Abstract as JDBC | Selenium 2(it bridge the API to JSON calls) |
| ORM as peewee or SQLAlchemy to ensure DB agnostic | PageObject provides agnostic on selectors and page details |
Based on project experiences, PageObjects offers below three functions to automation:
| Traditional App Dev terms | Selenium PageObject Sections |
|---|---|
| DB Table Structure as create, alter operations | Web Elements Encapsulation as lazy init, multiple selectors, and, retries |
| Select/View A snapshot of state | Pages define the states of sceanrio |
| Transaction Procedure | Functional methods provides interaction on pages, some of them triggers state transition, either return a new object of page or change the internal states |
It can be utilized to design test suppport classes for database, CLI (especially tree view cli), interactive shell and desktop applications. The key is to design abstract objects to represent the internal relationships between states and adjunct methods to fetch/operate the POI(points of interests, I borrowed this concept from MapSys design).
Therefore, the PageObjects here formed a layer to separate test logics and supporting objects. When people are drafting tests, we don’t need to switch to OOD part to spend time “thinking” about how to implement it and finally find out we forget the original motivation or target to do. This makes a concentration.
PageObjects Pattern or Bot Style Test?
it’s not always a pattern that teams feel comfortable following.
Alternatively there is Bot Style in test and test automation. Following PageObjects style, one turns to draw a state transition map on paper or in mind, no matter it is automation or manual test. For Bot Stylte, the test is designed against action steps (user scenarios). It is not to see which style is “better” in a quick glance. Here I am trying to provide some tips on finding the correct technique within the project characters and constrains. Usualy no matter in manual or automation, Bot Style is the first technique to utilize at beginning to get more domain knowledge while doing sanity test. Bot Style focus on the encapsulation of interactive actions so it is consistent to the test description on test plan or user manual.
