breaking 90% of test automation best practices to reduce code source ( notice not test count, test execution time, nor mention of efficiency, delivery time or anything related to product release or quality improvements.
have the locators in each page object class as By variables or
use page factory which declares the web elements and their locators together
In my opinion, using object repositories in Selenium projects is a bad practice.
The object repository concept comes from record-and-playback tools such as QTP.
The object repository is a tree-like structure that is created while recording a test.
It has attributes for each element of the page used in the test.
Selenium does not have any record-and-play feature for test automation (Selenium IDE is not an automation tool).
Using object repositories in Selenium projects (as property or csv or xml files) has many disadvantages such as
since each locator is a line in a text file, it is impossible to open the declaration of the locator in the IDE (using F3 or Open Declaration)
page object classes with no locator variables break the class encapsulation principle (methods of a class should execute on variables of a class)
object repositories do not scale well for big pages; since big pages are bad and should be broken down in small pages, should we not have object repositories for each page widget?
Telerik Test Studio failed miserably with a client - obscene situation ensued until I fought for ditching the UI joke & invest in code-based solution ( same Telerik framework ).
BUT...
there are no absolutes..
OL's can be leveraged to great effect in certain scenarios
Data Driven Testing
massive database of permutations ( API Testing ) would justify creating 'machinery' or a 'test engine' where POM is over-engineered design pattern for acute UI actions.
After critical mass reached,
the larger the UI, larger the disaster
First automation experience predates the concept of 'elements'
WindowsNT fat client
Point Of Sale with sprawling UI
multiple flavors for each client
Object Repo was MOUSE COORDS
This worked because the UI was RARELY changed
once UI decided, neither client nor development firm want changes
Client - costs for training, financial errors due to user confusion, brand damage for wait times during acclimation, new manuals, etc
Developer - forking UI for each client increases cost for everyone - along with greater risk.
What are the disadvantages of an object repository?
It is very difficult to read or change the value of an element locator
An ecommerce site has more than 50 pages, each with hundreds of elements.
We will have then an object repository for each page.
While working with code, there are many times when we need to either read or change the value of a locator.
Usually, this is done in the IDE (Eclipse, Intellij) by pressing the F3 key or selecting Open Declaration for the locator variable:
This does not work with object repositories since a locator is just a line in a text file.
To read or change the locator value, you have to
find the object repository for the page
open it
search for the element name in the file
That’s a lot of work for just reading a locator value.
Page Factory
Not a fan
Assumes only one locator needed
fails miserably with CKEditor's.. "nameless iframe with html/body tag"
Hunts down ALL elements on page instantiation
Not sure how this works with AJAX call back for 'mutli-value' fields with 'add another' button
