Rails TestAdapter API for native Ferrum usage

[YusukeIwaki]

Hi, I’m the author of playwright-ruby-client, and I’ve recently been working on rails/rails#57903 . I also maintain capybara-playwright-driver, and one motivation for this work is the considerable effort required to implement and maintain a Capybara driver layer.
The PR introduces a Capybara-independent option for Rails system tests, together with a small integration API currently called TestAdapter API.

For example, a Ferrum adapter could look like this:

class FerrumAdapter < ActionDispatch::SystemTesting::TestAdapter
  global_helper :browser do
    browser = Ferrum::Browser.new(**options)
    on_teardown { browser.quit }
    browser
  end

  helper :page do |browser:|
    page = browser.create_page
    on_teardown { page.close }
    page
  end
end

Users could then select it like this:

class ApplicationSystemTestCase < ActionDispatch::ServerSystemTestCase
  testing_with :ferrum, window_size: [1920, 1200]
end

And system tests would interact directly with Ferrum’s native objects and API:

class LoginTest < ApplicationSystemTestCase
  test "login with a single tab" do
    # `page` is a Ferrum::Page provided by the Ferrum adapter.
    page.go_to("http://localhost:28017/login")
    page.at_xpath("//input[@name='login']").focus.type("username")
    page.at_xpath("//input[@name='password']").focus.type("password123")
    page.css('input[type="submit"]').click
  end
end

The adapter would not wrap or normalize Ferrum’s browser API. It would only manage the lifecycle of objects such as Ferrum::Browser and Ferrum::Page and expose them directly to tests.

My impression is that this would make integrations for Playwright and Ferrum considerably smaller and easier to maintain than Capybara drivers, while allowing users to work directly with each library’s native features.
Since Ferrum also has Cuprite as its Capybara driver, I’d be interested in your perspective:

• Does this match your experience, or are there important benefits of the Capybara driver model that I may be overlooking?
• Are there any hooks or extension points you would add to or change in the TestAdapter API?

I’m mainly interested in feedback on the API design from the perspective of someone who has experience maintaining both browser-automation library and its Capybara driver. A high-level opinion would be very helpful; there’s no need to review the entire Rails PR.