3

I have been POM design pattern with pagefactory from past ~ 4 years. In current project again I have implemented same pattern, but there are not so many pages infact majority of test cases work on 1 single page.

I want to drop the idea of using POM, but then which one should I choose. Which design pattern other than POM, is tested enough, has better results and has been appreciated by client?

  • A PageObject doesn't have to be only a whole page, it can represent a fragment of a page, especially when the page the page is highly dynamic. You you can use separate PageOjects for the Menu, Body, Master, Detail, Banner, Footer fragments of a single page. Map any PageObject to a single functional aspect of a dynamic page. – Martin Spamer Oct 16 '18 at 19:53
1

Yes if the application is limited, the screens are similar and the locators are few, don't worry about a Page Factory for every page, just have one that all the specs share. Now 'limited', 'similar' and 'few' are obviously subjective terms and are really going to depend on other factors within your organization and also the ways in which pages do really differ and are similar.

I face this decision 18 months ago and, against the objections of others decided that one single data structure was the best route. Our actual implementation itself changed several times btw from static strings to hash values to dynamic methods but that was all irrelevant to the topics of how to break out Page Objects.

For a year this was the right decision - many values were shared among all our workflows and it was easier to follow the css selector patterns we were using by just editing 1 file.

Eventually we out-grew this and it was time to change. A couple of warning signs that we need to do this were:

  • Some identifiers were repeated as duplicates because the Page Object file had hundreds of line entries and no clear way to organize them
  • Some identifiers were no longer used by our workflows but the identifier were left because developers didn't know if they were used elsewhere.

After some growth it made more sense to break out the page objects into groups. For us this was:

  • Database identifiers used on INPUT fields as generated by Ruby on Rails. We made a common data store (ok, 'file') for these and included it with any workflows that required it.
  • Flow/page specific identifiers (often for navigation). These we put in separate files that were included by the spec or specs that needed them for the workflow under test.

Once we had done this it became a lot easier to edit specs, update Page Objects, avoid duplicate Page Objects and remove old unused Page Objects.

I also learned from this that even with the new structures it is really helpful to put in checks for your standards ('Test your tests'). I developed two to try and help 'keep the house in order':

  • A test (part of the test suite) that takes the db page object file and (via unix uniq command) makes sure that the file has all unique entries by comparing number of lines in original and in .uniq version.
  • A test (part of the test suite) that goes through each line in the Page Object file and makes sure that it is used by a spec somewhere
1

Your question is more a system design question than an automation question. For this reason, I'm going to point you to how I achieved the same end result as what you want for my own automation product. Once you understand the design, rolling your own should be easy.

I wrote a simple generic Page Object which just works for every webpage out there. Since you wanted to avoid writing page objects, my approach should help retain the well understood POM idiom while letting you get away without writing Page Objects.

It uses the facade design pattern mentioned elsewhere in this thread to dispatch messages to dynamically created page objects.

Dynamic page object src code = src/main/java/in/ramachandr/automation/core/extras/PageObject.java (sorry, I don't have sufficient reputation to post more than two links per answer)

Dispatch code: look at the setNextPage() method. It gets the next page object based on the URL and sends webdriver commands to it.

    protected void setNextPage() throws Exception {
    String url = driver.getCurrentUrl();
    URI url2 = new URI(url);
    url = url2.getPath();
    AbstractPage x = mapper.get(url);
    if(x != null){
        if(!x.equals(currentPage)){
            this.completePendingAsyncTasks();
        }
    } else {
        x = PageObjectFactory.getInstance(url);
        this.addPageObject(x);
    }
    currentPage.transferControlTo(x);
    currentPage = x;
    Assert.assertNotNull(currentPage, "No Page Object found for " + url);
    currentPage.map(currentPage);
}
0

You could use the 'facade' pattern. You put all methods for every single page into one class, create an instance of that class and just use that object to make every single call. This makes it easier to use and develop but pretty hard to maintain as the application grows more complex.

https://en.wikipedia.org/wiki/Facade_pattern

I want to clarify - POM is not just about the number of pages, it is also about modeling different page components into objects. So if your single/few page application has many components, POM is still a nice pattern to use.

  • What you describe doesn't sound like a Facade. A facade would be a class delegating invocations to single small PageObjects. What you describe sounds rather like anti-pattern called God object: en.wikipedia.org/wiki/God_object. – dzieciou Jul 8 '16 at 7:02
  • @dzieciou - I agree that facade badly done (and it is hard to do right) can devolve into a God class. I think I framed my answer as facade since the question states that the majority of the test cases work on only 1 page. – qxf2 Aug 7 '16 at 13:33
0

Very common question. Before few months I was faced this case. @paul - Thanks for taking this up here.

I will suggest, Use Page Object Model (POM)

  1. Design Patterns - Real helpers to build structure of project or code.
  2. It add further advantage of maintain and updation/modification code with ease
  3. Don't be hurry to calculate no. of pages to automate and choose design pattern
  4. Majorly it helps to understand others code too

Using and following design pattern is smart move. I'll recommend to follow while automating any application regardless of platform and scope !

  • @paul, what decision you have made? Which design pattern choosen? Surely provide updates and notes too. – NarendraC Jul 8 '16 at 21:26

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.