Wait For Asynchronous Text Changes #211
Open
Comments
Would I put these private functions above any of my test cases and call them down in the actual test? I struggled to implement the above solution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current matchers
visible_in_page?/1
andvisible_in_element?/2
currently immediately return the body/element if it is found. It will then try to immediately match thepattern
against the body/element.Problem:
If you are making an asynchronous change to the text within the body of the page or element, a race condition exists where those methods may return the body/element before the change has been made. Thus, this can cause 'flapping' failures.
For a use case that I think is fairly common, say I have a counter that updates when a user makes some action, which fires an AJAX request.
I understand that this is a bit of a loophole in the WebDriver spec since there is no way to select an element purely by its text.
Solution
For Hound? Not sure, but it would be nice if there was some matcher or other way to have Hound to retry a matcher for text a couple of times before failing. Similar to how
make_req/5
works.Quick Solution
For those that want a quick workaround, I found two ways to implement this on my own.
visible_in_element?/2
with a couple of retries. Here's how I implemented it. It's a bit crude, but works.find_element/2
with the:xpath
strategyelement?/2
with the:xpath
strategy and an assertionI haven't benchmarked any of these solutions, but testing them manually, they all seem to take about the same time when running the test.
I'd be interested in putting together a PR to add this, but not sure the feelings on this feature and how best to add it.
The text was updated successfully, but these errors were encountered: