使用Capybara和无头Chrome运行功能测试时的EOFError

Question

编辑:事实证明,整个问题是由于我们的WEBrick项目中隐藏且名称不佳的猴子补丁,Capybara将其用作默认的Web服务器.StackOverflow不允许我删除这个问题,所以在进一步阅读时要小心.

我们正在尝试将Ruby版本从2.2.7升级到2.4.3.该应用程序本身运行良好,但我们通过Capybara和无头Chrome(与Chromedriver)运行的所有功能测试突然失败.

以下是我们看到的确切错误的示例:

Failures:

  1) New UI - Settings Page - API with an unpermitted tier clicking on the "Request API Key" button shows a feature popup
     Got 0 failures and 2 other errors:

     1.1) Failure/Error: Unable to find matching line from backtrace

          EOFError:
            end of file reached

     1.2) Failure/Error: Unable to find matching line from backtrace

          EOFError:
            end of file reached

以下是我们为无头Chrome配置Selenium驱动程序的方法:

CHROME_BINARY = ENV.fetch('CHROME_BINARY', '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')

Capybara.register_driver :headless_chrome do |app|
  Capybara::Selenium::Driver.new(
    app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(
      'chromeOptions' => {
        'binary' => CHROME_BINARY,
        'args' => %w(no-sandbox disable-gpu window-size=1440,900 headless)
      }
    )
  )
end

Ruby版本:2.4.3

Chromedriver版本:2.35.528157

水豚版:2.18.0

RSpec版本:3.7.0

selenium-webdriver:3.9.0

Chrome:64.0.3282.167

我所做的所有其他研究表明,将Chromedriver更新到最新版本将解决此问题,但我们已经在使用最新版本(2.3.5).

我无法找到一种方法来获得上述错误的更多回溯.规范甚至没有达到从数据库加载任何东西的程度,它只是立即失败.

另外需要注意的是:在我们的CI服务器和本地开发机器上都发生了同样的确切行为.我们将CircleCI与Dockerized Linux容器一起使用,将MacOS Sierra/High Sierra用于我们的开发机器.

我们没有使用chromedriver-helper或任何其他自动安装chromedriver的gem.chromedriver的安装是通过brew install chromedriver或从chromedriver网站下载最新的chromedriver并放入我们的$PATH.

Answer 1

更新:这个问题的根源是WEBrick的monkeypatch.它命名不佳,位于一个不寻常的位置,作者不再在团队中.一个很好的提醒,应该不惜一切代价避免使用monkeypatches.

原始答案:

我一直在与乔丹(OP)就此问题进行合作.虽然我们没有找到根本原因,但我们发现没有回溯的EOFError来自哪里.

可以在Ruby的标准库中找到以下代码: Net::BufferedIO#rbuf_fill

https://github.com/ruby/ruby/blob/v2_4_3/lib/net/protocol.rb#L185

# callers do not care about backtrace, so avoid allocating for it
raise EOFError, 'end of file reached', []

我的猜测是这段代码的作者希望在某些时候能够挽救这个错误.也许有一个错误允许错误到达我们,没有回溯.

正如我所说,我们从未找到根本原因.然而,我们确实将其缩小到我们能够找到可接受的工作的程度.这个问题似乎与Webrick有关,Webrick是capybara默认使用的服务器,如果没有另外指定的话

• 当一个新的水豚会话被初始化时,Capybara :: Server的一个实例被"启动",这在我们的案例中是webrick:https://github.com/teamcapybara/capybara/blob/2.18_stable/lib/capybara/session.rb #L88
• 部分启动过程是检查服务器是否"响应":https://github.com/teamcapybara/capybara/blob/2.18_stable/lib/capybara/server.rb#L105
• 响应方法get向服务器发出请求(127.0.0.1):https://github.com/teamcapybara/capybara/blob/2.18_stable/lib/capybara/server.rb#L82
• 此时剩下的就是ruby的http lib.最终它在这里失败了EOFError:https://github.com/ruby/ruby/blob/v2_4_3/lib/net/protocol.rb#L185

我认为Webrick反应异常,或根本没有回应.如果有人对此事有进一步的了解,我很乐意学习.

在我们的例子中,解决方法很简单.该应用程序已经在其他环境中使用美洲狮,所以我们决定尝试puma与capybara,看看它是否让我们解决这个问题:

Capybara.server = :puma

由于不再使用Capybara的机架式服务器,我们不再受到影响.

如果其他人遇到同样的问题或有关于根本原因的想法,请分享!

编辑1:

在逐步执行代码时,我抓住了caller到达时的结果rbuf_fill.对于那些感兴趣的人,我在这里上传了它:https://gist.github.com/benjaminwood/c7c0d39fcfb2efd8a9085874cac07c36

编辑2:

有关Webrick作为Capybara默认服务器的更新信息.感谢@Thomas Walpole澄清这一点.

编辑3:

添加关于分辨率的注释(这是一个monkeypatch).