About to embark on my first automation effort with framework - advice needed!

(James) #1

Hi All,

I have just completed an automation framework course and am now trying to write a framework from scratch for the application I am responsible for testing. The first page I need to a test and POM for is essentially a customer details input form that consists of a number of text boxes, radio buttons and drop downs. Before I start working on this, I just wanted to see whether I’m on the right track.

So, my proposed way of doing this would be for the test to have a line for each thing that the customer needs to input, using clear names for each one and then implementing each method, along the lines of:

TEST
CustomerName("Type customer name here but leave blank for default name);
CustomerSex.Male or CustomerSex.Female

POM
CustomerName [ADD CODE TO SELECT CORRECT FIELD]
CustomerSex [ADD CODE TO SELECT CORRECT FIELD
Male/Female [ONE METHOD EACH; WILL SELECT CORRECT RADIO BUTTON OPTION]

Does this sound acceptable?

Thanks

sad_muso

(Chris) #2

Hi,

I would say you’re on the right track. With the POM, you have a single place should something change with the element of interest. That makes your framework maintainable.

I would also make the methods in POM static and also add additional helper methods too. For example,
I would add a wrapper around CustomerName in the POM. I’d create a static method called something like setCustomerName which would call the CustomerName method and do the sendKeys step too.

So, in your test, you could write…

POM.setCustomerName("John");

Why would I do this? It makes the code more maintainable and in your test, there would be less boilerplate (get element, send text to element, assert element contains sent text). I’d put the assert in the POM helper methods. Your test would be more readable then too.

E.g.

POM.setCustomerName('John');
POM.setSexMale();
POM.submitForm();
(Mark) #3

I wish people would stop using POM, it’s a maven Project Object Model. I’m guessing you mean you want to use a Page Object model.

I would suggest looking at using Fluent API’s with page objects. You can effectively create your own DSL (Domain Specific Language) for your tests and make them nice and easy for other people to read. You will then be able to chain the methods in your page objects so that they look something like this:

PageObject page = new PageObject(); page.setCustomerName("Jim").setGender(MALE).submitForm()

In the example above I’m assuming that MALE is part of an ENUM. You can then stick a simple case statement in your setGender() method that works out which radio button to select.

Remember that page objects are badly named and don’t have to be a definition of a complete page, they are just a useful abstraction for a group of related things. You can have a page object model that pulls in multiple different page object models to build a codified view of your page that’s not too big or complex.

Its fine for a method in a page object to return a new instance of another page object, but think about the possible places it could go. For example if you are automating a login form you probably have a few locations that are viable:

  1. Successfully login
  2. Change password screen
  3. Failed login

In this case having the command that clicks the login button returning a specific page object is probably a bad idea, you would probably want to have login return an instance of itself and add some helper methods that return the relevant page object based upon what your check is expecting e.g.

loginPage.username("Jim").password("Password123").submit().successfulLogin()

loginPage.username("Jim").password("Password123").submit().failedLogin()

DO NOT make everything static, it’s a massive anti-pattern. Remember test code is as important as production code, spend time making it as good as you can.