-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@timeout annotation is forcing implicit waits onto users #111
Comments
summon @artkoshelev |
I've done a little more investigation since posting this and unfortunately not had the time to take it further. I at least understand why the @timeout feature has been built this way - selenium unfortunately don't provide a way to get at the implicit wait setting so you've been forced to implement a complete replacement for selenium's implicit timeout setting. This feature is a great idea, selenium's implicit wait implementation somewhat resembles a sledgehammer and is damn near impossible to customise. I still have two issues with the current implementation though:
So in short, I still think the current @timeout implementation could be improved:
|
@andrew-sumner thank you for investigating the problem
|
I have to disagree with you about 0 second wait being as unexpected as a 5 second wait: From the selenium documentation: http://www.seleniumhq.org/docs/04_webdriver_advanced.jsp
and also
Clearly anyone who is using implicit waits expects that the default would be zero. I know that yours is an alternative implementation but surely it's best to conform to existing behaviour where possible? I've also looked into the history of this feature and 9 months ago the HtmlElementLocatorFactory was changed from:
to:
which I would argue is the breaking change and has altered the expected behaviour for anyone using this project. I'm happy to provide a PR to address documentation and a better way of setting default timeout, but I really would like to get some agreement that the default timeout should be zero... Wait Strategy TestsI've run some tests as I was curious to see what would happen with different wait strategies, source code is at https://github.com/andrew-sumner/htmlelements/tree/timeout/htmlelements-java/src/test/java/andrew System.setProperty("webdriver.timeouts.implicitlywait", "0");
System.setProperty("webdriver.timeouts.implicitlywait", "5");
System.setProperty("webdriver.timeouts.implicitlywait", "5");
|
If you dig a little deeper, you'll find this commit existing almost from the very beginning of project. Using default implicitly wait will save you a lot of code and nerves. Mixing it with explicit waits is not unpredictable, but has expected limits, so will not harm. In rare case of testing specific timeout on element you can annotate it with |
I give up, close this if you want. I'll be creating a custom locator factory for use on my projects that default to a 0 second wait. I get that you guys like implicit waits, but there is a large community out there that do not and this project as it stands doesn't cater well to us. I personally find that I only need to wait on one or two elements on a page, the majority of the time waits (implicit or otherwise) just aren't required so even if I do use the timeout annotation I will still set the default to 0. I can't recommend enough that you add some documentation to highlight this behaviour. |
Do we have any ability to set default timeout to 0 instead of 5 seconds without setting @timeout ? |
@IZaiarnyi please ask your questions on stackoverflow |
+1 for removing implicit waits or sync them with driver. Just investigated performance problems with our autotests and figure out 2 problems:
We had a special implicitWait setting for driver but as I figure out it won't help. VM option webdriver.timeouts.implicitlywait setted to 1 just make our tests 4 time faster.
|
There is one more issue related to this. If I want to disable implicit waits completely via System.setProperty("webdriver.timeouts.implicitlywait", "0"); I am getting exception in case I want to interact with any of WebElement initialized with HtmlElementLocatorFactory
If I set timeout to 1 second, everything works good. |
@artkoshelev no, I am using release 1.18 version from maven. How to take latest snapshot version from maven? |
@Zlaman just change version to |
Unfortunately it does not work. Looks like maven central cannot store snapshot versions, only releases. Example of pom.xml <?xml version="1.0" encoding="UTF-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>ru.yandex.qatools.htmlelements</groupId>
<artifactId>htmlelements</artifactId>
<version>1.19-SNAPSHOT</version>
</dependency>
</dependencies>
</project> |
We've been using JitPack use the lastest version. |
As issue #108 (and PR #110) has been closed prematurely and I cannot reopen it, I've started a new issue.
@ianwen Regardless of how long its been in use, the currently implementation alters the default behaviour of selenium and I consider it to be a bug.
You were right to reject my PR but you've done it for the wrong reasons. I was a bit hasty with my original PR as my implementation would likely have overridden the timeout set by
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
and made it zero - which is just as bad as the currently implementation which I believe forces it to 5.The behaviour I would like to see is:
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
on that particular element - currently @timeout overrides this setting globally even if like me you don't use itwebdriver.timeouts.implicitlywait
should be removed - it was a poor design choice.If you still don't want to change the @timeout implementation then I'd like to see the opinions of a few other project members on this issue rather than just yours as I believe this issue is rather important.
Yes, its easy to work around as you highlighted when closing the previous issue, but in most cases:
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
but the current implementation of @timeout completely overrides that behaviourIf you are not willing to improve the timeout behaviour then at the very least the projects readme must be given a section devoted to the @timeout annotation and its flaws.
The text was updated successfully, but these errors were encountered: