Modern web applications rely on dynamic content, interactive features, and responsive designs to provide a seamless user experience. Ensuring that these applications perform optimally requires extensive testing of both the frontend and backend components. For Rails applications, Capybara and Selenium WebDriver are commonly used tools for testing frontend functionality, while Docker provides a lightweight containerization platform for easy deployment and scaling of your application.

This guide will examine how to set up a testing environment for your Rails application frontend using Capybara and Selenium WebDriver within a Docker container. We will also discuss important considerations when choosing the appropriate configuration for your tests.

Introduction to Capybara and Selenium WebDriver

Capybara is a popular acceptance test framework for Ruby web applications that simulates user interactions with your application in a browser. It provides a high-level API that allows you to interact with your application's UI elements, navigate between pages, fill forms, click buttons, and perform other actions as if you were an actual user.

Selenium WebDriver is an open-source browser automation framework widely used for automating web browsers through programs and performing browser automation. It supports various programming languages like Java, C#, Python among others. When combined with Capybara, it enables developers to run tests across different browsers (Chrome, Firefox) without changing the test code.

Setting Up Your Testing Environment

To set up your Rails application frontend testing environment using Capybara and Selenium on Docker:

Install Docker: If you don't already have Docker installed on your system, follow the official installation guide.

Configure Capybara: In your Rails project's test directory (or spec if you're using RSpec), create or update the test_helper.rb (or spec_helper.rb) file with the following Capybara configuration:

require 'capybara/rails'
require 'capybara/minitest'

Capybara.register_driver :chrome_headless do |app|
  Capybara::Selenium::Driver.new(
    app,
    browser: :remote,
    url: 'http://chrome_selenium:4444/wd/hub',
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome('goog:ChromeOptions': { 'args': %w[ignore-certificate-errors no-sandbox headless disable-gpu] })
  )
end

Capybara.default_driver = :chrome_headless
Capybara.javascript_driver = :chrome_headless

This configuration sets up a new Capybara driver called chrome_headless that uses the Selenium WebDriver to connect to a remote Chrome browser running in headless mode.

Create a Dockerfile for your Rails application, if you haven't already. The Dockerfile should include instructions to install your application's dependencies and set up the runtime environment.

Create a docker-compose.yml file in your Rails project's root directory with the following contents:

version: '3'

services:
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/app
    ports:
      - "3000:3000"
    depends_on:
      - chrome_selenium

  chrome_selenium:
    image: seleniarm/standalone-chromium:4.1.2-20220227
    logging:
      driver: json-file
    networks:
      - network
    volumes:
      - /dev/shm:/dev/shm

networks:
  network:

This configuration sets up two services, web and chrome_selenium, which are your Rails application and the Selenium WebDriver running in a headless Chrome browser, respectively. The web service depends on the chrome_selenium service.

1. Start your Docker containers using the command docker-compose up.

With this setup, you can now create and run frontend tests for your Rails application using Capybara and Selenium WebDriver within Docker containers.

HTTPS Testing Considerations

When testing HTTPS-enabled applications with Capybara and Selenium, it's crucial to be aware of HSTS (HTTP Strict Transport Security) preload lists that may enforce HTTPS connections. If your application's domain is included in an HSTS preload list, any HTTP connection attempts will automatically be redirected to HTTPS by modern web browsers.

To avoid complications during testing, ensure that you're using a domain that's not included in an HSTS preload list. Chrome and Firefox use the same preload list, which can be found in the Chromium source code.

Additionally, avoid using generic or widely-used TLDs (Top-Level-Domains) which may be on the browsers HSTS preload list (SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List - MozillaWiki), the most common is .dev (which is now owned by Google - …/transport_security_state_static.json · Gerrit Code Review) but you can check the whole list in Chrome source code (Firefox uses the same): chromium/transport_security_state_static.json at master · chromium/chromium · GitHub.