You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👋 Hi, I hope it's ok to open feature requests here, I'm happy to work on it, I'd just like to ask for feedback first.
Problem
We're having a problem in Rails system tests (full details here rails/rails#45994) that may require some help from capybara to properly fix.
Because of transactional fixtures (tests are ran inside a transaction), we need all threads to use the same database connection. Which mean both the main thread that runs the test case and the various puma threads use the same databse connection.
So to avoid race conditions we have to put a lock around all DB access. The problem arise when applications have multiple database, threads sometimes need to lock all connections to invalidate the cache and it can cause deadlock.
Ultimately, locking around the database connection isn't ideal, it would be much cleaner to acquire a single global lock when starting the test, and have a Rack middleware acquire that lock too so that we ensure Puma can only process requests when the test is doing Capybara assertions.
Example:
require"application_system_test_case"classHomePagesTest < ApplicationSystemTestCasetest"visiting the index"doPost.create!(title: 'my title')visit'home_page/index'Animal.create!(name: 'cat')assert_selector"h1",text: "HomePage"endend
In the above example we'd like to be able to implicitly lock and unlock as follow:
require"application_system_test_case"classHomePagesTest < ApplicationSystemTestCasetest"visiting the index"do# lock when starting the testPost.create!(title: 'my title')# unlock when calling the capybara drivervisit'home_page/index'# relock when doneAnimal.create!(name: 'cat')# unlock when calling the capybara driverassert_selector"h1",text: "HomePage"# relock when done endend
Problem
This is relatively simple on paper, however in practice it is hard to ensure that all the possible driver methods are covered.
It would be very helpful if Capybara had a "chokepoint" method we could redefine, e.g.
e.g. if Session instead of:
driver.visit(visit_uri.to_s)
Would do something like:
call_driver(:visit,visit_uri.to_s)
It would be even better if Capybara provided a first class hook API around these calls.
The text was updated successfully, but these errors were encountered:
👋 Hi, I hope it's ok to open feature requests here, I'm happy to work on it, I'd just like to ask for feedback first.
Problem
We're having a problem in Rails system tests (full details here rails/rails#45994) that may require some help from capybara to properly fix.
Because of transactional fixtures (tests are ran inside a transaction), we need all threads to use the same database connection. Which mean both the main thread that runs the test case and the various puma threads use the same databse connection.
So to avoid race conditions we have to put a lock around all DB access. The problem arise when applications have multiple database, threads sometimes need to lock all connections to invalidate the cache and it can cause deadlock.
Ultimately, locking around the database connection isn't ideal, it would be much cleaner to acquire a single global lock when starting the test, and have a
Rack
middleware acquire that lock too so that we ensurePuma
can only process requests when the test is doing Capybara assertions.Example:
In the above example we'd like to be able to implicitly lock and unlock as follow:
Problem
This is relatively simple on paper, however in practice it is hard to ensure that all the possible driver methods are covered.
It would be very helpful if Capybara had a "chokepoint" method we could redefine, e.g.
e.g. if
Session
instead of:Would do something like:
It would be even better if Capybara provided a first class hook API around these calls.
The text was updated successfully, but these errors were encountered: