Question 1. What are Page Object Models?
A Page Object Model (POM), at its simplest, is a selenium file which specifically lets you control a single page of your website.
Question 2: Why use them?
Simply put, having the POM file defined means that you can code your tests, without your tests having to know exactly how your page is constructed.
Also, if there are any changes to the web page, then you only have to change the POM file once, and not change the x number of tests that cover that page.
Question 3: How can I use them?
Step 1: Define your POM file. This is done by the following:
In the loginPOM.java file:
Define your controls on the page. e.g. txtUsername, txtPassword, btnLogin, btnCancel.
Define some helper functions, e.g.
loginWithDetails(strUsername, strPassword) (which populates the username and password fields with the supplied values),
isLoginErrorShown() (which detects if a validation error is shown on the screen), etc.
Step 2: Define your tests.
In the loginTest.java file, for each test, instead of doing this:
Find username field.
Set field to “username”.
Find password field.
Set field to “password”.
Find <Login> button.
Click <Login> button.
Find the validation error message.
Check the validation error content… etc.
you can simply write
// Test 1: Invalid username/password
loginWithDetails(“baduser”, “badpassword”)
assertTrue(isLoginErrorShown())
// Test 2: Valid username/password
loginWithDetails(“gooduser”, “goodpassword”)
assertFalse(isLoginErrorShown())
So this makes the tests easier to read, and easier to write.
Going back to the “Why?” question, you can see that if the name of the “username” field changed, then (if each test was written out long-hand), each test would have to be recoded to use the new field name. But when using the login POM, only the one function loginWithDetails() would need to be refactored to match the new name. All of the unit tests that use the POM would be cheerfully oblivious of the change.
So… that is a very brief into to POMs, and why they are very useful.
