{ "version": "https://jsonfeed.org/version/1", "title": "Capybra on enumerator.dev", "icon": "", "home_page_url": "https://enumerator.dev/", "feed_url": "https://enumerator.dev/feed.json", "items": [ { "id": "https://enumerator.dev/end-to-end-tests-with-minitest-and-rails/", "title": "End To End Tests with Minitest and Rails", "content_html": "

willow.camp has a small system test suite that runs on CI. It used to use the out-of-the-box settings that come with Rails: Capybara, Selenium, etc.

\n

I noticed a flaky test on CI, which launched a journey to replace Selenium with Cuprite.

\n

Fixing the Flaky Test

\n

I worked through the flaky test with Claude Code, and as Claude was running the tests, I noticed this pop-up from Chrome.

\n
\n

A data breach on a site or app exposed your password…

\n
\n

I don’t use Chrome very often, so this jumped out at me. Of course, I use the oh-so-secret password “password” in my test suite, and Chrome flagged it as unsafe.

\n

Disabling password leak detection fixed this for me.

\n
browser_options: { "disable-features": "PasswordLeakDetection" }\n

But I still got timeouts on CI that looked like the tests were running before the browser was ready.

\n

Waiting for CI is a bit painful. You can see my hilariously bad Git history with Claude’s gleeful overconfidence:

\n
* 0c514d1 - nosandbox (15 minutes ago) <Cassia Scheffer>\n...\n* 57ac55b - bump timeout to 30 sec for ci (21 minutes ago)\n* 9d6e86e - rewirite cuprite/capybara configs (26 minutes ago)\n* 39f3238 - fix: simplify Cuprite configuration following best practices (10 hours ago)\n* 68bfd53 - fix: simplify Cuprite configuration and fix CI timeout issues (24 hours ago)\n* cebfae7 - fix: resolve Cuprite websocket timeout issues in CI (24 hours ago)\n* dc288b7 - fix: make Cuprite configuration more robust for CI environments (24 hours ago)\n...\n* e5bb4df - fix: increase Cuprite timeout and add CI-specific settings for GitHub Acti>\n...\n* cb36eaa - feat: migrate system tests from Selenium to Cuprite (35 hours ago)\n* 39f0ff1 - disable selenium chrome password detection (35 hours ago)\n

That Looks Bad, Cassia. Why Would You Let Claude Do That!?

\n

Because Claude is faster at making mistakes than I am, and I am tired of waiting for CI. Making mistakes quickly means speedier feedback. So I sent Claude off on a fool’s errand to help me learn from the mistakes I would otherwise have made myself.

\n

In the meantime, I read the Evil Martians article about better system tests.

\n

Using Cuprite in Rails with Minitest

\n

The Evil Martians article on system tests uses RSpec, but willow.camp uses Minitest. Here’s what I had to change to make it work with Minitest.

\n

1. PrecompileAssets becomes a module and gets called when setup runs.

\n
# Precompile assets before running tests to avoid timeouts.\n# Do not precompile if webpack-dev-server is running (NOTE: MUST be launched with RAILS_ENV=test)\n\nmodule PrecompileAssets\n  def self.setup\n    # Check if we're running system tests by looking at the test files being loaded\n    running_system_tests = caller.any? { |line| line.include?("test/system") } ||\n      ARGV.any? { |arg| arg.include?("test/system") } ||\n      ENV["RAILS_TEST_TYPE"] == "system"\n\n    unless running_system_tests\n      puts "\\n🚀️️  No system test selected. Skip assets compilation.\\n"\n      return\n    end\n\n    puts "\\n🐢  Precompiling assets.\\n"\n    original_stdout = $stdout.clone\n\n    start = Time.current\n    begin\n      $stdout.reopen(File.new(File::Constants::NULL, "w"))\n\n      require "rake"\n      Rails.application.load_tasks\n      Rake::Task["assets:precompile"].invoke\n    ensure\n      $stdout.reopen(original_stdout)\n      puts "Finished in #{(Time.current - start).round(2)} seconds"\n    end\n  end\nend\n\n# Run the setup when this file is loaded\nPrecompileAssets.setup if defined?(Rails)\n

2. BetterRailsSystemTests Becomes a Moduel

\n
module BetterRailsSystemTests\n  # Make failure screenshots compatible with multi-session setup.\n  def take_screenshot\n    return super unless Capybara.last_used_session\n\n    Capybara.using_session(Capybara.last_used_session) { super }\n  end\nend\n

3. Modules are included in ApplicationSystemTestCase

\n
require "test_helper"\nrequire "capybara/cuprite"\nrequire_relative "system/system_helper"\n\nclass ApplicationSystemTestCase < ActionDispatch::SystemTestCase\n  include BetterRailsSystemTests\n  include CupriteHelpers\n\n  driven_by Capybara.javascript_driver\n\n  def setup\n    super\n    # Use JS driver always\n\n    # Store original host for cleanup\n    @original_host = Rails.application.default_url_options[:host]\n    # Make urls in mailers contain the correct server host.\n    # This is required for testing links in emails (e.g., via capybara-email).\n    Rails.application.default_url_options[:host] = Capybara.server_host\n  end\n\n  def teardown\n    # Restore original host\n    Rails.application.default_url_options[:host] = @original_host\n    super\n  end\nend\n

Flakiness Still Included on CI

\n

I still see a bit of system test flakiness on CI, but far less than before. I am running on the default GitHub Actions runner, which is pretty small. So there’s a good chance that the flakiness is due to low resources on the machine. So far, tests have consistently passed when I run these on my M1 MacBook Air.

\n

I’ll dig into these flaky tests another day! But this looks like an improvement overall to me!

\n", "date_published": "2025-08-13T22:27:26+00:00", "url": "https://enumerator.dev/end-to-end-tests-with-minitest-and-rails/", "tags": ["willow-camp","rails","capybra","minitest"] } ] }