Hacker News Reader

Comment by stephen | Hacker News Reader

FWIW the most consistent (as in non-flaky) selenium tests I've worked with used hidden DOM elements to synchronize the selenium driver with the JS code:

http://www.draconianoverlord.com/2011/10/14/sane-selenium-te...

Basically every JS ajax call (or JS promise, though we didn't use any of those at the time) would update a hidden DOM element's inner text, e.g. the `#pendingAjaxRequests` inner text would go to 1, or 2, then back to 0 when the AJAX response came back (ideally you do this instrumentation in a single place in your app).

Then on the selenium side, after every button click/other action, we'd wait until those counters went back down to zero.

This post-action waiting (waiting for the app to "settle" after invoking actions) vs. pre-action waiting (...well, this the element I want to click on available yet? Hm...no...) was very reliable.

View on HN

What do you think of this approach instead:

http://cabeca.github.io/blog/2013/06/16/waiting-for-complete...

When I did this type of workaround (I have not needed to write one of these for a while) I found it was a problem for control flow that I needed to know if the action actually started and finished, not just whether it was currently in progress.

I used an .ajax-processing class that I added at the start of the request, and removed when the request came back with a callback.

While I can see the advantage of pendingAjaxRequests instead (you could have more than one going at a given time, and my .ajax-processing breaks down there), it still seems like you could have a problem as the browser JS is not running in the same process as your server or your test executor.

Your next line of code might run before the browser increments the inner text, or starts the XHR. You could pass control flow on thinking that the event has already completed, when in reality it hasn't even started yet. The 2013 article I linked seems to have a more robust model for tracking requests, it's just two variables, but it would seem to handle this problem with perfect reliability.

The approach you linked to looks good to me. I hadn't seen that before; thanks for sharing it!

> Your next line of code might run before the browser increments the inner text, or starts the XHR.

Yeah, that is true in theory, but we never had a problem with that--my mental model was that if the Selenium process issued a click, and it got sent to the browser, any "onclick" behavior would fire within that immediate event loop (and for our app that's where we issued any AJAX calls, immediately within that event loop), tick up the hidden DOM count, before the webdriver code that's sitting within the browser sends back the response to Selenium client.

I've not examined the webdriver impls of each various browser, but AFAICT my theory matches what we saw at the time (in google/firefox with native events enabled).

I'd be very interested to hear from someone authoritatively on whether this theory is actually correct.

Also, if you have a JS-side persistence layer that does AJAX calls in separate event loops, e.g. with setTimeout, then yeah I could see this being an issue and would necessitate a more deliberate approach (like your linked post, which I like).

If your client talks to server, which talks to API, and your server is running in a different process/machine than your client integration tests (in our case, with Capybara.run_server=false) you will find this happening all the time.

The next server operation isn't done until both client-server and server-API communications have finished. And in any case API server is likely to need to confer with a database server before it can return its response, so it will take longer.

There are many good reasons not to run this way, but so far we have not found any better way for our Windows developers to do tests locally than with Capybara.run_server=false set in their environments. (They are using Vagrant and a process from 3+ years ago, and our developer envs need a serious refresh for 2017 imho...) And it helps for the argument that in real life, your servers and your users will not be in the same thread.

If your stack is tightly coupled and your tests run strictly with both client and server locked against a GIL, you will in all likelihood absolutely never hit this case. Even if your server does actually hit remote services, but the server and client thread in testing are joined by a lock, your client thread will wait for the server to return and you will still probably never hit this issue.

It is not a production-facing issue, in any case the kind of errors that you can hit if you arrange your testing infrastructure in a way to expose these problems... are not problems that you will ever see a user complaining about in production. If you don't have this problem, don't go looking for it in other words, because it's a pain! It's been a pain for us, but not by any means impossible to work past.

Our ruby developers on Windows found this happened a lot more frequently than when I ran my tests on MacOS (where I did not need run_server=false.)

I'm running against a local selenium webdriver that was spawned by Capybara's selenium driver natively. (In other words, it's cool when everything is housed in a single process-thread. The way that any sane person would do their testing deployment. But for my Windows users with Vagrant boxes, another way is needed of course...)

We set our Jenkins server up to run similarly decoupling the stack from the client selenium/test integration and by applying resource constraints to make the right parts slow, for us it was absolutely 100% reproducible.

I've done this twice. It's the only way I've ever gotten any sanity out of Selenium.

> I've done this twice. It's the only way I've ever gotten any sanity out of Selenium.

What are the benefits of this approach vs. explicitly waiting for the things that should appear in the page?

>There are a variety of ways of doing this, but you basically need a choke point in your application where all AJAX requests go through.

Does wrapping the XMLHTTPrequest object to get this functionality still count as sane?

Yep! We technically had our own layer on top of XMLHTTPRequest to use a centralized slice point instead, but AFAIK wrapping it directly would be great too.

Interesting! Thanks for the reference. I think all the waiting I have dealt with is server (vs. animation) as well. I'll have to play around with this idea...

sounds like an interesting pattern.

it would be nice to have a browser extension that abstracts the pattern in the browser.

Reply on news.ycombinator.com