Welcome to the newest post of the Huddle Selenium series.
Each month on the first Tuesday of the month, we will post a new blog post to take you through a step-by-step guide on how to address a particular aspect of using Selenium as part of our How To series. This post continues Anton’s guide on using Page Objects with Selenium.
This is the ninth article from the WebDriver Page Objects Series. There are important details that you need to consider before choosing how to implement the Page Object design pattern in your test automation framework. One of them how and where to access your web elements. In this publication, I am going to share with you four different variations.
If you are using WebDriver often, you may find useful my Most Complete Selenium WebDriver C# Cheat Sheet. All you need to know- the most basic operations to the most advanced configurations.
Test Case
We will once again automate the main Bing page. All of the code is placed inside the BingMainPage class.
1st Version Elements Exposed as Public Properties
The first version uses partial classes again. Here the elements are located in a separate file ending with the suffix Elements. Since the elements are public, you can access them in the page files and in the tests as well.
BingMainPage.Actions Public Properties Version
BingMainPage.Elements Public Properties Version
BingMainPage.Asserts Public Properties Version
BingMainPage Public Properties Version in Tests
In the second tests, you can see that we can access the page’s elements from the tests.
2nd Version Elements Exposed as Private Fields
BingMainPage.Actions Private Fields Version
All elements can be accessed only on this layer since they are private. It is not a problem to use them in the Actions file since the partial classes will be combined in a single type.
BingMainPage.Elements Private Fields Version
Now all elements are renamed to follow the private fields’ naming convention. Their names begin with the “_” prefix.
BingMainPage.Asserts Private Fields Version
BingMainPage Private Fields Version in Tests
Now you are not able to access the elements directly in the tests. This might be your preferred approach if you do not want to expose WebDriver specific logic in your tests. This way the users of your framework are obligated to hide all of the nitty gritty details in the pages.
3rd Version Elements Exposed as Protected Fields
BingMainPage.Elements Protected Fields Version
We can make all fields protected instead of private if the page object will be used as a parent for some child page where you need to access these elements.
BingChildPage.Actions Protected Fields Version
The usage in tests stays the same.
4th Version Elements Exposed as Public Property
BingMainPage.Actions Elements Public Property Version
Since the elements class is now not a partial to the above one, we create a public property to access all of the elements. This way, you will be able to access the web elements on a test level.
BingMainPageElements Elements Public Property Version
If you take a closer look, you will notice that this time the elements class is not a partial one. This is so because now we access all elements through the public property located in the Actions file.
BingMainPage.Asserts Elements Public Property Version
To verify the text in the div, you need to get it from the Elements property.
BingMainPage Elements Public Property Version in Tests
The first test we use the page the usual way. In the later, we can access the elements through the public Elements property. It is a matter of taste whether you want to see all elements in the IntelliSense or to access them via a property. Personally, I prefer to see all elements.
In future articles, I will share with you other modifications of the design pattern that can make your tests even more maintainable. You can find even more articles dedicated to the design patterns in automated testing on my site: Automate The Planet.
See more articles in the How To Selenium Series
About Anton Angelov
I am the Founder and Editor in Chief of Automate The Planet. My passion is taking software quality to new heights through the integration of the best practices in the Quality Assurance and Automated Testing. I have considerable professional experience (6+ years) as a Senior Automated Testing Architect. Currently, as QA Architect and IT Consultant, I am improving the tooling and processes in a company named Innovative Lab. I am ardent about technologies such as .NET Framework, Azure, Bot Framework, SQL Server, Selenium WebDriver, and Jenkins. Outside my work as a consultant, I am an IT trainer leading training related to high-quality code, design patterns and automated testing.
