The Page Object Pattern is a popular design pattern used to represent services provided by a page (reads the rendered page you see on your screen). Whilst this is a good pattern to drive the application under test, it should not be visible to the test class.
- The test class is no longer isolated from internal code changes
- Binds the test class to the underlying technology/library
- Low-level code details pollute the test class
The test class should represent the domain behaviours only, not the implementation. There are benefits to doing this:
- Your test is readable by engineers and non-technical colleagues
- Your test is resistant to superficial changes. Only a change to the domain behaviour will cause your test class change.
- Your test is technology agnostic, i.e. you are not bound to a particular technology.
- It improves discoverability for users of your framework.
Let’s examine an example:
From the above code, think about what happens in the following scenario:
a. The search engine changes from
b. If the method name changes from
c. If the underlying library changes from
Let’s refactor the test class in Figure 1.1 to focus on the domain behaviour removing the Page Object.
Assume the tests verifies:
(Note: this is a trivia example, for illustration only)
As you can see there are no references to any page objects, instead domain wrapper classes are used to represent the business language.
Let’s revisit the earlier questions based on the refactored test.
Test class is not aware of what engine is doing the search, so the test doesn't need to change
The test only cares about the behaviour and results. Implementation is not the responsibility of the test.
The Test class is not bound to a specific library. In fact, you can use it as an API test without needing to change a single line
As with everything in life, context is key!
Understand and utilise what is best for your workflow or design decision(s).
However I’d recommend:
- Don’t let Page Objects bleed into your test.
- Test classes should only focus on business scenarios.
- Your test should focus on behaviour instead of implementation.