Selenium Chrome在Rails Rspec Docker环境中启用事务处理夹具后看不到数据库更改

Question

I'm so close yet so far from getting my Selenium tests working in my new Docker dev environment.

I recently did a big upgrade from ruby 2.4.2 to 2.6.3 . Around the same time I also switched from a local environment to a setup with Docker. Everything migrated fine except for this one last issue.

With browser tests, it appears that the browser can't see the changes to the database, for example, when I create a user, and then log in through the web UI on the browser, the returned webpage says "user and pass doesn't not exist". Also, the changes don't appear in the database even in the middle of the test, though I think that's normal when transactional_fixtures is enabled.

The problem goes away when config.use_transactional_fixtures = false . But then I have to deal with database cleaning, which I tried and was also problematic. Note that this all worked fine in ruby 2.4.2 on my local MacOS.

I can access the browser via VNC on port 5900 and see the tests running fine until it needs to do anything that requires data from the db, like logging in via the browser with a username that was created programmatically in the spec.

It's not clear to me where the database information goes if it's not in the database, or how the browser can access this data? This article seems to discuss the relevant issue of Capybara and the web server sharing the same db connection to access uncommitted db changes. But I'm still lost after several days 🤦‍♂️

Here are my configs.

Dockerfile

FROM ruby:2.6.3
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client pdftk xvfb

RUN wget https://chromedriver.storage.googleapis.com/2.41/chromedriver_linux64.zip
RUN unzip chromedriver_linux64.zip
RUN mv chromedriver /usr/bin/chromedriver
RUN chown root:root /usr/bin/chromedriver
RUN chmod +x /usr/bin/chromedriver

RUN echo "chromedriver -v"
RUN chromedriver -v
RUN mkdir /myapp
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
ENV BUNDLER_VERSION='2.0.2'
RUN gem install bundler --no-document -v '2.0.2'

RUN echo $BUNDLER_VERSION
RUN bundle install
COPY . /myapp

# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

# Start the main process.
CMD ["rails", "server", "-b", "0.0.0.0"]

docker-compose.yml

version: '3'
services:
  db:
    image: postgres:9.6.15
    volumes:
      - data:/var/lib/postgresql/data
    environment:    
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
    ports:
      - "5432:5432"
  web:
    build: .
    command: bash -c "rm -f tmp/pids/server.pid && RAILS_ENV=test bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db
    links:
      - selenium
  redis:
    image: redis:alpine
    command: redis-server
    ports:
      - "6379:6379"
  sidekiq:
    depends_on:
      - db
      - redis
    build: .
    command: sidekiq -c 1 -v -q default -q mailers
    volumes:
      - '.:/myapp'
    env_file:
      - '.env'

  selenium:
    image: selenium/standalone-chrome-debug:3.0.1-germanium
      # Debug version enables VNC ability
    ports: ['4444:4444', '5900:5900']
      # Bind selenium port & VNC port
    logging:
      driver: none
      # Disable noisy logs.

volumes:
  data: 

spec/rails_helper.rb

# This file is copied to spec/ when you run 'rails generate rspec:install'
require 'spec_helper'
ENV['RAILS_ENV'] ||= 'test'
require File.expand_path('../../config/environment', __FILE__)
# Prevent database truncation if the environment is production
abort("The Rails environment is running in production mode!") if Rails.env.production?
require 'rspec/rails'
# Add additional requires below this line. Rails is not loaded until this point!
require 'support/factory_bot'
require 'support/session_helpers'
require 'support/record_helpers'

@both = ['artist','gallery']

# Requires supporting ruby files with custom matchers and macros, etc, in
# spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are
# run as spec files by default. This means that files in spec/support that end
# in _spec.rb will both be required and run as specs, causing the specs to be
# run twice. It is recommended that you do not name files matching this glob to
# end with _spec.rb. You can configure this pattern with the --pattern
# option on the command line or in ~/.rspec, .rspec or `.rspec-local`.
#
# The following line is provided for convenience purposes. It has the downside
# of increasing the boot-up time by auto-requiring all files in the support
# directory. Alternatively, in the individual `*_spec.rb` files, manually
# require only the support files necessary.
#
# Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f }

# Checks for pending migrations and applies them before tests are run.
# If you are not using ActiveRecord, you can remove this line.
ActiveRecord::Migration.maintain_test_schema!

RSpec.configure do |config|
  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = true

  # RSpec Rails can automatically mix in different behaviours to your tests
  # based on their file location, for example enabling you to call `get` and
  # `post` in specs under `spec/controllers`.
  #
  # You can disable this behaviour by removing the line below, and instead
  # explicitly tag your specs with their type, e.g.:
  #
  #     RSpec.describe UsersController, :type => :controller do
  #       # ...
  #     end
  #
  # The different available types are documented in the features, such as in
  # https://relishapp.com/rspec/rspec-rails/docs
  config.infer_spec_type_from_file_location!

  # Filter lines from Rails gems in backtraces.
  config.filter_rails_from_backtrace!
  # arbitrary gems may also be filtered via:
  # config.filter_gems_from_backtrace("gem name")


  config.include Features::SystemTestHelpers#, type: :system

end

# fixes a glitch in most recent chromedriver or chrome where it can't access remote URLs
# https://github.com/teamcapybara/capybara/issues/2181
require "selenium/webdriver"

Capybara.app_host = "http://web:3000"
Capybara.javascript_driver = :selenium_chrome_headless
Capybara.run_server = false

Capybara.register_driver :selenium_chrome_headless do |app|
  capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
    chromeOptions: { args: %w(no-default-browser start-maximized enable-features=NetworkService,NetworkServiceInProcess) }
  )
  Capybara::Selenium::Driver.new app, browser: :remote, url: "http://selenium:4444/wd/hub", desired_capabilities: capabilities
end

entrypoint.sh

#!/bin/bash
set -e

# Remove a potentially pre-existing server.pid for Rails.
rm -f /myapp/tmp/pids/server.pid

bundle install

# Then exec the container's main process (what's set as CMD in the Dockerfile).
exec "$@"

An excerpt of a spec that's breaking

spec/system/record_gallery_spec.rb

require 'rails_helper'

feature 'User creates a work' do

  scenario 'with most fields filled out', driver: :selenium_chrome_headless do 
    gallery_sign_in

    visit new_work_path
    # breaks here ^^

    ...

  end
end

the helper function referenced above

def gallery_sign_in(user: nil, id: nil, custom_pdf: nil)
  user = create(:user, id: id, custom_pdf: custom_pdf) unless user
  user.role = 'gallery'
  user.save

  visit login_path
  fill_in 'user[email]', with: user.email
  fill_in 'user[password]', with: user.password
  click_button 'Login'
  return user
end

Answer 1

Rails 5.1 does support sharing the DB connection between the Application under test and the tests (transactional testing) but only if you're letting Capybara start the instance of the application under test, since the tests and the app need to be running as separate threads under the same process. You're specifically telling Capybara not to to run the app under test ( Capybara.run_server = false ) and instead telling it to run against an app instance you're starting separately ( Capybara.app_host = "http://web:3000" ). In that configuration there is no way to share the DB connection between the tests and the AUT so you have to disable transactional testing ('config.use_transactional_fixtures = false') and use database_cleaner (or something else similar) to handle resetting the DB between each test.