selenium 2.0: Design pattern for projects which doesn't have so many pages

  • 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?

  • 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

Suggested Topics