5 ms·

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 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).

yebyen 9y ago
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.

yebyen 9y ago

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.