Opened 11 years ago
Closed 10 years ago
#21158 closed Cleanup/optimization (wontfix)
Set an implicit wait for selenium.
Reported by: | Florian Apolloner | Owned by: | bsilverberg |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Tim Graham | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Selenium often tries to access elements before the page is loaded; it offers an implicitly_wait method which we could utilize and it might fix a few of our timing issues; I'd suggest a relatively high timeout of 10 seconds to cover our bases. See https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/remote/webdriver.py#L626 for this method.
Change History (9)
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 11 years ago
comment:4 by , 11 years ago
Has patch: | set |
---|
comment:5 by , 11 years ago
I'd advise a little caution on this approach. I've worked on projects which have assertions that just want to verify that an element is not on the page. If every such assertion takes 10 seconds of redundantly verifying that the element is still not on the page, that can make the tests take a lot longer to run. It's a pain to correctly do it consistently, but I've had better results fixing tests with implicit timing dependencies to wait explicitly when appropriate.
comment:6 by , 11 years ago
Thanks jmbowman. That certainly can be an issue. I ran the current test suite and it doesn't seem to suffer from this issue. In the suites that we use at work we do have a default implicit wait set up, and then we use helper methods when we want to check that an element is not present which switch off the implicit wait.
I think the approach used here is appropriate for the current test suite, but it is something to be careful about in the future, if this approach is adopted.
comment:7 by , 10 years ago
Cc: | added |
---|---|
Patch needs improvement: | set |
I left an idea for improvement on the pull request.
@apollo13, any thoughts on the comments in the thread? Was the idea to commit this and see if it helps with the random failures on Jenkins?
comment:8 by , 10 years ago
We currently don't have any random failures (or at least not really often), so I think we can close this for now.
comment:9 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
I have opened pull request https://github.com/django/django/pull/2543 for this. This is my first django pull request so any advice/feedback would be appreciated.