0

So I've written a good amount of scripts using Capybara with Selenium Web-driver. It's going well but my automation tests feel more like step by steps scripts, without much Object Oriented design or foresight.

I've read about the Page Object Model with Selenium and it makes sense...however most examples are in Java (Which makes sense because Java+Selenium is so common) but also the examples are usually simple in a sense that Page Object Model makes sense with that sort of tests.

I'm in a predicament, because the web application I want to implement Page Object Model is unique in that it's multiple steps (Think each page having a new form and new user type). So there isn't really a place where something is "commonly" used among multiple parts of the app. (Besides maybe referring to a "Title" or "Username" occasionally. It's quite a complicated app.

In something like this does POM make sense? If so how would you set it up? Make each step it's own method perhaps (Which is essentially a gigantic form, sometimes even 10-15 inputs). This feels a bit strange because if I'm actually making this single step a method, then I'm passing a huge amount of parameters to do the form.

What makes sense here? Is POM even a good idea if there isn't really much duplication when doing a "happy-path/main functionality" run of the web application.

  • 1
    I code in Java and not Ruby, but I'm sure the advantages of POM would still apply. The methods in the POM are as granular or as complex as you want to make them, from a simple buttonClick to a complex registerUser(String name, String blah, ...) The advantages of POM to me are many unless the project is truly small. – Bill Hileman May 9 '18 at 15:31
1

Even though you might not be re-using elements on multiple pages, or re-use the same pages for different tests (that's how I understand it), I would say using the POM still has benefits:

  • The code is more future proof, if you do want add more tests for alternative scenario's it should take less effort. Without a proper implementation that supports re-usability for page elements, adding more test scenario variants might force you to duplicate css selectors/xpaths and your codebase will turn into spagetti
  • The code will have a clear structure and if some element on a page (in the tested application) changes, then it is really clear where you need to update that in the code. You are almost sure that you only need to change it in one place.
  • The actual tests are decoupled from the page definitions. If for some reason you want to use a different test framework (i.e. switch from Capybara to something else), it is really clear that the page classes are not affected and you only need to change the tests.

On the page classes, I would define methods that accept domain specific test data objects. I.e. you could have a Person object that has attributes such as first name, last name, data of birth, etc. In your tests you can either initialize these objects with hard code values, or you could have some mechanism to configure different sets of data per environment. This might reduce the amount of arguments for a method on a page class from 15 to 3 or something.

  • On the flow I probably go through...20 something pages of different forms. Should each "Page/Form" be a different class? Some of these forms are 20+ inputs. Should each input on the form be a different method or? – Mercfh May 11 '18 at 13:20
  • 1
    I would probably make a page class for each of the 20 pages. Use inheritance and define common elements in the parent class (i.e, next step buttons). I have no idea what kind of data is filled in per page, but I would suggest using one method to fill in data that is related to each other, i.e. one method to fill address fields, on for person data. You can then still choose to wrap those methods with one method for the complete page. There is no solution that works best all the time, it really depends on what data is filled in, what kind of test case variants you expect to have, etc. – Pieter A May 11 '18 at 14:12
  • That makes sense (On the data filling), since a lot of the forms have "sections" IE: Personal Info, etc.... – Mercfh May 11 '18 at 14:28
2

POM can be useful to avoid unnecessary refactoring. For your development stack I would suggest installing the site_prism gem - it allows you to easily create and compose page objects.

In this Pull Request you can see examples that I wrote, showing how the aforementioned gem separates clearly the page object components, its functions and how to use them with Capybara (or any other framework).

Some configuration is necessary, but the README explains it throughly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.