Applying the "page object" pattern with stb-tester
02 Sep 2015. By William Manley.
Often you will hear us recommend that you should structure your test-packs as a set of library functions, plus test-cases that use those library functions. In this blog post we attempt to make this recommendation more concrete by demonstrating how to apply the “page object” pattern when writing stb-tester test-cases.
Here’s what a test-case can look like when applying the page-object pattern:
and this is what it can look like without:
The improvement in understandability is clear. Without the page-object, the
meaning of your test-case is buried in the forest of calls to
wait_until. Using the page-object pattern means that your
test-case consists of high level concepts that expose the intent of the
test-case. Notice that with the page-object pattern calls to
almost never appear in test-cases directly.
In this example the page-object is
guide. This is an instance of a class that
knows how to understand and navigate your set-top-box’s programme guide.
The class might look like this:
The class is used by many test-cases, which increases code reuse. It serves as a central place to handle any known quirks of your UI, and as a single place to update if your UI changes.
If you need to test multiple similar (but slightly different) variants of your UI with a single test-pack, this class is the place to abstract over those differences.
Note that I made
open_guide a standalone function rather than a method or
static method of class
Guide. I don’t consider navigating to the guide to
belong to the
Guide page-object. Rather it belongs to the app as a whole. The
rule of thumb is that the methods on the
Guide class are only valid to call
if the guide is currently visible.
So, using the page-object pattern:
- Improves the readability of your test-cases.
- Reduces the maintenance cost of your test-pack by sharing (and thus reducing) test code and providing a central place to apply fixes and updates.
- Assists with reusing test-cases for testing multiple variants of a single UI.
In next week’s blog post we will discuss an extension to this approach called the “Frame Object Pattern” which can improve the maintainability of your test scripts even further.