Selenium 3.11 Released

So, Selenium 3.11 was released. What exactly does this mean for you?

Below, I will help you to understand the new features and one huge challenge that has now been added with this release.

Say Goodbye to PageFactory

If you look at the release notes for Selenium .NET release of 3.11, the PageFactory.cs is moving to a different Nuget package.

Honestly, I’m grateful… the implementation caused many problems for many users. Such as the infamous StaleElementException.

This change reduces complexity in the Selenium code base and will stop people from posting examples online using the PageFactory 👏🎉

This in no way means that you should stop using Page Objects Pattern. This is totally a separate concept. You can use Page Object Pattern without the PageFactory.cs. The latter is just a Selenium implementation that has no relation with a design pattern.

“The .NET implementation of these constructs was created mostly because some users asked, “Java has it, so why doesn’t .NET?” Rather than blindly copying the Java implementations as was done, it would have been better to think about what actually makes sense when using C#. In other words, “C# isn’t Java, and therefore the things that work best for Java may not be entirely appropriate for C#.” In the case of the .NET PageFactory, the implementation was problematic and cumbersome, as well as not nearly flexible enough for the myriad ways people wanted to create Page Objects. Additionally, when .NET Core 2.0 was released, the classes upon which the .NET PageFactory relied were not included .NET Core 2.0. This meant that to get the PageFactory working under .NET Core, the project either had to take on a new dependency, mangle the code with conditional compile directives, or leave it unsupported in .NET Core. The first approach is a non-starter for the Selenium project’s .NET bindings, the reasons for which should be a subject of its own blog post. The second approach made the code nearly impossible to properly maintain. Furthermore, with respect to the PageFactory in particular, there is no benefit to be gained by identifying elements via an attribute over doing it directly in runtime code. Claims that the PageFactory made Page Object creation and maintenance less verbose simply do not hold up under close scrutiny.”

Jim Evans, maintainer of C# bindings

ExpectedConditions.cs is being deprecated

If you’ve grown to love the WebDriverWait and ExpectedConditions.cs as I have, this comes as a blow.

When I first saw this, I did a double-take… Huh? What?

So why did the .NET implementation of ExpectedConditions move to a separate code base?

According to my conversation with Jim Evans, here is why:

Yes, it reduces the size of the code base, as well as the maintenance burden. It reduces the number of times the maintainer has to respond to issues and PRs for that class. This is the proper path forward for the community to be able to enhance and maintain these methods, as the class provided by the Selenium project was frozen long ago, with PRs adding new methods being rejected.

Look:

I’ve never contributed any code to Selenium and have never had to maintain it. But I do know that software maintenance can suck…

So we do all that we can to reduce it. However, in this case, it seems to be a mistake.

I personally use the ExpectedConditions.cs on a regular basis. And I find it very useful.

Here’s the deal:

As a user of the software, my life should be easy. Instead, I now have to write my own lambda expressions to figure out if an element is in a valid state on a page.

Ugh! Definitely extra work for me. Especially when I mess up the logic 🙁

Again, I don’t support the project and don’t understand their point of view. But it seems silly to remove maintenance work from the project by decreasing usability for the end user.

But what do I know? When I create a software like Selenium, maybe then I should be allowed to complain 🙂

Instead, I’ll stop whining and tell you how you can fix these problems…

So what can you do?

First, prepare yourself for the loss of PageFactory. If you are taking my Complete Selenium WebDriver with C# course, you don’t have to worry about this 🙂

Second, prepare yourself for the broken code that will occur on a future Selenium version (>3.11) when the Selenium project removes ExpectedConditions.cs.

To deal with this problem, you can download the Nuget Package called DotNetSeleniumExtras.WaitHelpers. Then, just reference the appropriate namespace in your files.

Also, don’t forget to do this in your using statements so that ExpectedConditions is being used from the correct Nuget package:

using ExpectedConditions = SeleniumExtras.WaitHelpers.ExpectedConditions;

Here’s a code example of me using this class:

0
6 Shares
Share5
Tweet1
Share
%d bloggers like this: