ProtractorJS: A better way to implement page objects.
Page objects, recommended in the Protractor docs, are a popular pattern for writing end-to-end tests for Angular but they quickly become lists of ugly, boilerplate selectors that break when you decide to change your DOM. They do an excellent job of separating view logic from test logic, but they are mangled with references to models, css, and bindings that are none of their business. Plus, you have better things to do with your life than write page objects… like go learn how to milk a goat or study Gaelic.
Not bad, but do you really want your test to break just because you decide to rename your “showDeleteModal” function?
They also move logic out of your tests so that you have to look up the relevant page object before you can understand a test. Separation of concerns is good but so is getting shit done.
Wouldn’t it be cool if you could select elements with the same syntax that you are used to with page objects, without having to write the page objects? And what if you could still do this while keeping your test logic separate from your view logic? With a few minor extensions to protractor, you totally can!
To accomplish this, we add a what attribute to our element to identify it semantically and a which attribute to distinguish it from other items repeated in a list:
Now we can select elements without using ids, classes, bindings, or models. Our new attributes are only used for testing, so we know not to mess with them when we’re refactoring our code or we’ll break our tests. This also gives us the added benefit of having extremely readable tests: I wasn’t really able to follow By.xpath(“//*[contains(text(), ‘” + name + “’)]”)) but I totally understand what “author list” and “save button” mean.
But there’s still room for improvement. Let’s extend protractor to give ourselves a more readable syntax (I’ll tell you about our protractor-extras module to do this in one line later):
Now we can write that as:
Which means that now we can change our ids, model names, classes, and bindings all we want without breaking anything. This is also readable enough that we can use it directly in our specs without the need for page objects.
Here’s what the final result looks like:
Once ES6 proxies are supported by our test browser, we will be able to use properties instead of methods to get elements, just like our original page object syntax:
page.authorList.authors.which(“Chris”)
But that’s a little ways out — Chrome revoked it’s experimental support for Proxies in version 38.
“But what about helper methods?!”, you ask. Despite wanting to kill page objects, I have to admit they can still sometimes be useful. They serve nicely as a place to put helper methods — for example, we create an author four times in our authors spec, so I kept our authors page object just to house the createAuthor method. With our new syntax, most tests won’t require page objects, but occasionally you may want to use one to organize reusable methods.
If you like this pattern and want to implement it, you can use our protractor-extras module to import these extra methods:
And that’s it. This extends the protractor and global objects.
If you found this post interesting, check out cjroth.com and follow me on Twitter.
