I have non-deterministic failures on my Cucumber tests that occur after the end of some tests. It would seem that when the browser/cucumber steps finish, there are still undergoing requests being processed on the server , and they seem to keep running even while DatabaseCleaner runs and drops documents, which results in failures when trying to access the model in the server.
When my app creates users, they are stored in an instance variable @users = []
for easy access. When I catch those exceptions, I realize the variable is still there @users.first.present? # => true
but its document had already been removed @users.first.reload # => nil
.
I do not really understand where the problem comes from, since there shouldn’t be extra page loads (maybe Turbolinks/caching playing tricks on me), and the failure seems really nondeterministic (fails 1/3 times, even at different places in the code)
I’d rather avoid to set Capybara.raise_server_errors == false
although it would most likely fix things for those tests
I was wondering if you had similar problems and how you coped with that…
2
Answers
I feel sooo stupid. I had an "image zoom modal" which was used to display bigger version of images when clicked on. This modal was initialized with an
img
attribute, and since the src was supposed to be updated through a click() event, with my poor knowledge I had initialized it withsrc="#"
.This was causing the browser to request the image at the same path of the current request (and I didn't notice but the hint was that the second request was of type
*/*
instead of HTML/JS, etc.). In that case, Capybara would often finish the test after receiving the updated DOM after the "original request", while the "image request" was still undergoing.Just changed it to
src="file://null"
following some other questions advice.Not sure, there might be issue with database cleaner strategy you are using
Whats your default webdriver & your database cleaner strategy?
Try @javascript tag before scenario or feature. It will use selenium as current webdriver which uses database cleaner ‘transaction’ strategy default.