In the ongoing process of doing my code work on my Github, I came across an idea that I’d actually encountered before. But it was one for which I’d never previously had an identifying term, and I was excited to learn about this.
Namely, Page Object Model testing. (Not to be confused with Project Object Model, which is what the POM in a pom.xml file stands for when you’re working with Maven.)
What this is: a way of writing a test framework that separates “code that represents the thing you’re testing” from “code that actually does the testing”. Turns out I’d learned about how to do this at Big Fish, when I picked up the idea and how to implement in Python.
Back in those days, it helped to do this because it let me have test cases that basically said “okay go get me the page I need to test, and stick all the data representing it into this object, which I will then do tests against”. It meant that in setup for tests, all I had to do was go grab an instance of the object that represented the page to be tested. And that meant in turn that the tests themselves were more tightly focused.
I found that it required a bit more organizational work to set up, but that once I had the idea in place, it meant writing future tests became easier. For example, if I had test script A that tested the homepage of the site, and then later needed to write test script B against the same page, I wouldn’t have to rewrite the code that loaded the homepage for testing. Likewise, if something about the structure of the homepage changed, I would only have to change the class that dictated that structure, with possibly only minor changes to any test scripts that needed to deal with it.
I liked this way of organizing code well enough that I have been implementing it on my Github repos. In the Python Selenium demo, specifically.
But, now that I’m done with the initial wave of Selenium tests and am looking at ways to expand the suite in both Java and Python, I started thinking of how to rearrange the organizational structure of both suites and seeing whether I could do a similar structure in Java. That led me to discovering that this whole concept had a name.
And it also led me to being able to implement Page Object Model testing in the Java Selenium repo, too.
What this means in practical terms is that I can think of pages on my test WordPress site in terms of “here is an object that represents an entire page, including child objects”. These child objects would be things that are shared across all pages, like a sidebar, or a footer, or a menu. Their various objects are things I have to implement only once in a Page Object Model system, and then use as necessary in tests that actually look at them on different pages.
So all in all this has been a satisfying area of research.
Some links I’ve used to read up about this:
Page Object Model (POM) | Design Pattern on Medium.com
Getting Started with Page Object Pattern for Your Selenium Tests on Pluralsight.com