Skip to content
Permalink
Browse files

Marking .NET ExpectedConditions obsolete

This implementation of PageFactory for .NET is deeply flawed.
Additionally, using the ExpectedConditions provides no benefit over
directly using lambda functions (anonymous methods) directly in
one's code. Since the community appears to believe that an "official"
repository of wait conditions is desireable, the existing code has
been migrated to a new repository under a new organization on GitHub
(https://github.com/DotNetSeleniumTools/DotNetSeleniumExtras). It is
hoped that this will encourage a volunteer from the community to take
ownership of this code. Users should update their references and
migrate their code to use `SeleniumExtras.ExpectedConditions`. This
implementation will be removed from the .NET language bindings in a
future release.
  • Loading branch information
jimevans committed Mar 7, 2018
1 parent aafb326 commit 29b5be0a72331df9ab99e36b05b4c29cf7046f30
Showing with 2 additions and 1 deletion.
  1. +2 −1 dotnet/src/support/UI/ExpectedConditions.cs
@@ -1,4 +1,4 @@
// <copyright file="ExpectedConditions.cs" company="WebDriver Committers">
// <copyright file="ExpectedConditions.cs" company="WebDriver Committers">
// Licensed to the Software Freedom Conservancy (SFC) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
@@ -32,6 +32,7 @@ namespace OpenQA.Selenium.Support.UI
/// IWebElement element = wait.Until(ExpectedConditions.ElementExists(By.Id("foo")));
/// </code>
/// </example>
[Obsolete("The ExpectedConditions implementation in the .NET bindings is deprecated and will be removed in a future release. This portion of the code has been migrated to the DotNetSeleniumExtras repository on GitHub (https://github.com/DotNetSeleniumTools/DotNetSeleniumExtras)")]
public sealed class ExpectedConditions
{
/// <summary>

15 comments on commit 29b5be0

@nadvolod

This comment has been minimized.

Copy link

nadvolod replied Mar 11, 2018

I'm a bit saddened by the deprecation of ExpectedConditions. That class made it much easier and less verbose to use the WebDriverWait class 👎

@jimevans

This comment has been minimized.

Copy link
Member Author

jimevans replied Mar 12, 2018

@nadvolod Then the proper thing to do is to either (1) migrate to the replacement class provided by the new repository, or (2) create your own utility class that exposes the methods you think are most useful. The introduction of the ExpectedConditions class in .NET was a mistake. Unlike at the time when the Java version of the class was introduced, there has never been a time that the lambda syntax of C# has been not well-understood by the developers using it. If the community values a repository of "One True Way" wait conditions (and it seems like it does), the proper thing to do was for the community to create a companion project that provides those wait conditions. The deprecation of them in this project, and the splitting them out into another project that the community can take true ownership of is a way of correcting the mistake.

@nadvolod

This comment has been minimized.

Copy link

nadvolod replied Mar 12, 2018

@jimevans

This comment has been minimized.

Copy link
Member Author

jimevans replied Mar 12, 2018

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.

Once again, if you believe that having a class with static methods providing shorthand syntax (or standard implementation) for your project, there is nothing stopping you from creating that for your project. Furthermore, if you believe that concept to be something the community would benefit from, there’s nothing stopping you from releasing your class as an open-source library. This is what’s happening with the existing ExpectedConditions class. It’s being spun out so that the community can make of it what they desire, under the leadership of someone who has the proper vision of it to balance the community’s desire for a “one-size-fits-all” solution with the practical concerns of exploding the number of methods and overloads to unmanageable levels.

@nadvolod

This comment has been minimized.

Copy link

nadvolod replied Mar 12, 2018

@truthanb

This comment has been minimized.

Copy link

truthanb replied Mar 14, 2018

Got all switched over to the new packages for now. Thanks for the heads up, Jim.

Is something different, perhaps another concept coming along to support test maintainability in a way that would replace using pageobject modelling?

@jimevans

This comment has been minimized.

Copy link
Member Author

jimevans replied Mar 14, 2018

@truthanb Remember that use of the Page Object Pattern is completely independent of the use of the PageFactory. There is nothing in the concept of page objects that require you to use attributes to define and locate elements. The deprecation of PageFactory is in no way a repudiation of the Page Object Pattern as a design pattern.

@wackydude

This comment has been minimized.

Copy link

wackydude replied Mar 14, 2018

Example conversion code for new people like me:

using static SeleniumExtras.WaitHelpers.ExpectedConditions;
...
var element = wait.Until(ElementToBeClickable(By.Id("id")));

@Xaeroxe

This comment has been minimized.

Copy link
Contributor

Xaeroxe replied Mar 16, 2018

For what it's worth I'm strongly against the deprecation of ExpectedConditions. This is a definite downgrade for the ease of use of the library. At my company we have 3 people working on C# Selenium scripts and of them I'm the only one who regularly writes their own lambda functions for use with this.

Even then I only do this if for some reason the ExpectedConditions class doesn't have what I need. I prefer to use it if it can do what I need to. This provides an easy way to do a wide variety of common tasks and is huge boon for people who are just learning how to script. If I don't have this to point to I fully expect people to just use Thread.Sleep instead of a proper Wait.Until.

For the time being we're just going to copy the class and use it ourselves, but I don't think removing this class does anyone any good.

@jimevans

This comment has been minimized.

Copy link
Member Author

jimevans replied Mar 16, 2018

@Xaeroxe Help me understand how using the artifact from the new repository doesn't resolve your issue? What's the concern? That it's not part of the Selenium package anymore? If you want to copy the class locally, that's fine, you're welcome to do so, but the methods are still available in a binary form, even released as a package on NuGet to make it easier to consume. Moreover, moving these methods out to a new repository gives the community the chance to maintain them and enhance them to better suit the needs and desires of the community.

@Xaeroxe

This comment has been minimized.

Copy link
Contributor

Xaeroxe replied Mar 16, 2018

@jimevans What you propose will resolve my issue. The main thrust of my argument is that this functionality should be considered standard, not an extra add-on. The use cases for it are too many for selenium to not have a built in way to handle this in my opinion.

This is of course just my opinion, and I do have solutions to my problems. I mostly just wanted to share that for the purpose of keeping the C# bindings useful and easy to learn that this should remain part of the standard bindings.

@jimevans

This comment has been minimized.

Copy link
Member Author

jimevans replied Mar 16, 2018

@Xaeroxe I disagree with your opinion on what should and should not be included as part of the .NET bindings.

@Xaeroxe

This comment has been minimized.

Copy link
Contributor

Xaeroxe replied Mar 16, 2018

@jimevans Then in that case I'd like to volunteer to take over the DotNetSeleniumExtras repository.

@jimevans

This comment has been minimized.

Copy link
Member Author

jimevans replied Mar 16, 2018

@Xaeroxe Thank you for the offer. Let’s discuss it early next week via IRC/Slack?

@Xaeroxe

This comment has been minimized.

Copy link
Contributor

Xaeroxe replied Mar 16, 2018

Sure!

Please sign in to comment.
You can’t perform that action at this time.