Question about system tests and thread-safety

rubyonrails-talk
1

Hi all,

We have a Rails 5.1 app and we recently wanted to use system tests. However, upon adding them I noticed various weird-behaving issues like segfaults and stuff.

I suspect that this has to do with the fact that in system tests, a Ruby server (i.e. puma) is spawned in a thread, that has access to the same code that our tests use. In that case, what happens if our app is not thread-safe? Do Rails apps (their code + the gems they use) have to be thread-safe in order to use the system tests feature?

For example, in our app we have the following pattern, which I believe is not threadsafe:

module Drivers

this method is used by all of our application code that needs to access elasticsearch, so that we maintain a single connection.

But it’s also used inside our tests, so that we truncate data before/after specific test cases

def self.elasticsearch @es ||= Elastic::Client.new end end

``

So if the above method is accessed in a system test by both the server test (i.e. application code executed by puma) and the test code concurrently, it could result to subtle bugs. Is my understanding correct?

P.S. For the record, we use rspec with capybara and webrick as the server.

2

If you are running your Ruby code on MRI (the official implementation) there is no way to make your Ruby code any threadsafer. They have global interpreter lock in place.

Segfaults generally don't cause by Ruby code, and when it does it is a bug of the interpreter itself.

3

To provide a bit of background: until now, we used Unicorn in production so our thread-safe issues weren’t a problem for us (we don’t use threads in our code, even though some gems may do). And we tested with RSpec and Capybara, but without js: true (so without a server thread).

Now with system tests though, if we want to test JS, thread-safety becomes an issue since a server thread is spinned up and it might access the same code that our tests do. Is my assumption correct?