-
-
Save josevalim/470808 to your computer and use it in GitHub Desktop.
@kuroda - have you found a more systematic way to fix this issue? We're experiencing the same thing, and rather than run around fixing a bunch of tests, ideally there's a lower level way to address the problem.
We should work on a reliable solution for everyone.
The best take I've seen so far is @iangreenleaf's article and gem:
http://technotes.iangreenleaf.com/posts/the-one-true-guide-to-database-transactions-with-capybara.html
https://github.com/iangreenleaf/transactional_capybara
It bundles the shared connection monkey patch and the wait_for_ajax
helper.
Version 0.1.0 has just been released with support for Capybara >= 2.6.0.
It doesn't use connection_pool nor a Mutex.
I haven't had the need for it so far, but it's just a PR away.
Sorry to dig up an old thread (no pun intended), but I've been facing this issue on a Rails 5 app recently, and @mperham's solution worked great for me!
lol yeah this thread is filled with golden lessons in concurrency.
It’s 2019, do we still need this in Rails 5.2?
@gnclmorais, it seems that this is not useful anymore: https://github.com/teamcapybara/capybara#transactions-and-database-setup if you are running Rails 5.1 +.
The solution using
Mutex
(thanks to @mikecmpbll) andwait_for_ajax
(thanks to @divineforest) works well for me.Here is another tip from me.
In some occation, the
undefined method 'fields'
error can occur even if you callwait_for_ajax
after triggering an Ajax call.In fact, we have to wait for all database accesses are completed, not just for ajax.
Suppose that you have following scenario among others:
If any database access occurs after this scenario ends, we will get the
undefined method 'fields'
error on the next scenario.To prevent this problem, we have to write another expectation that is fulfilled only after all database accesses are completed.
For example, if we know that a text appears on the browser screen at the end of scenario, we can write like this: