In the last chapter of PageFactory in C#, we have learned that how to Design the Page Object Model using Selenium PageFactory. We learned that how beautifully we can design our PageObject classes and how easy and maintainable the automated test can be after implementing pagefactory.

But as told earlier that PageFactory instantiates all the elements of the web page at the start when we Initialized any page class objects. But think of the elements which will display on the web page after some action, say Ajax action. In PageFactory, every time when we call a method on the WebElement, the driver will go and find it on the current page once again. In an AJAX-heavy application this is what we would like to happen. So, in that case we are good to use the PageFactory as if the element appears later, the pagefactory will still look for the element on its turn.

But in the case of regular application where elements are stable and when we know that the element is always going to be there and won’t change. It would be handy if we could ‘cache’ the element once we’d looked it up and save some time of execution by commanding PageFactory to not search the WebElements on the page again.

PageFactory CacheLookup

PageFactory also provide CacheLookup attribute to cache the WebElements. This attribute helps scripts to instruct the InitElements method to cache the element once its located. In other words, any attribute marked [CacheLookup] will not be searched over and over again – this is especially useful for elements that are always going to be there (not always true for AJAX apps). It means the elements of the page will be cached once searched. All elements used in the HomePage & LoginPage class are static and are always present. So it is better to cache objects and save execution time of the test run.

How to use PageFactory CacheLookup

If we know that element is always present on the page, it is best to use the following declaration:

Notes

If you use the PageFactory, you can assume that the fields are initialised. If you don’t use the PageFactory, then NullPointerExceptions will be thrown if you make the assumption that the fields are already initialised.

List<WebElement> fields are decorated if and only if they have @FindBy or @FindBys annotation. Default search strategy “by id or name” that works for WebElement fields is hardly suitable for lists because it is rare to have several elements with the same id or name on a page.

WebElements are evaluated lazily. That is, if you never use a WebElement field in a PageObject, there will never be a call to “findElement” for it.

Advantages

When the PageFactory is initialised the proxies are configured, but the WebElements are not found at that point (so you won’t get a NoSuchElementException).

Every time you use a WebElement it will go and find it again so you shouldn’t see StaleElementException’s.

But when you use the @CacheLookup annotation, which is losing you the second benefit as it will find the element once and then keep a reference to it, you are now far more likely to see StaleElementExceptions.

Differences between C# and Java Implementation

In C# the PageFactory.InitElements returns void, where as in Java it returns the Page Objects.

The PageFactory implementation for C# only searches for elements using the ID. It does not locate the elements using the NAME property. Where as in Java it also tries to find the element with Name property, if it is not able to find it with ID.

The Java implementation can locate the element even without the FindsByattribute. This isn’t the case for C#.

For more updates on Selenium Tutorial in C#, please Subscribe to our Newsletter.

Please ask any questions on at ForumsQA, in case of any issues or doubts.