Modal dialog 强制水豚在意外模态下失败

我正在进行一些测试来触发和验证JS警报，如下所示：

it 'triggers a modal' do
  accept_alert('Hello world') do
    visit '/'
    click_button 'Button'
  end
end

这是失败的：

 Capybara::ModalNotFound:
       Unable to find modal dialog with Hello world

无头运行时，我认为对话框根本没有触发，这是我的JS代码的问题，但我注意到下面列出的测试日志：

* Listening on tcp://127.0.0.1:3001
Modal window has been opened, but you didn't wrap your code into (`accept_prompt` | `dismiss_prompt` | `accept_confirm` | `dismiss_confirm` | `accept_alert`), accepting by default
F

在全Chrome中运行时，我注意到模式正在被触发，并带有预期的消息。所以现在我不确定：

• 为什么我的

  accept\u alert

  如果消息实际上是错误的（例如，包含隐藏字符，消息实际上是

  Hello world\t

  或其他内容），则测试没有失败
• 自从我的accept块包裹了整个测试体以来，展开的模式是怎样的

我可能有一个愚蠢的语法错误，但我认为上面的说法是正确的&正在进行另一个测试。为了弄清真相，我想禁用水豚的“默认接受”

有没有办法：

是否使任何意外模式未能通过测试（而不是接受/拒绝）

在情态动词出现时注销其文本

---

默认情况下，接受不是由水豚完成的，而是由您正在使用的驱动程序完成的（我根据生成的消息假设是Cuprite）。如果您包装导致模式出现的操作（基于显示的行为，我假设

访问

），而不是整个测试，那么如果错误消息不正确，它将引发错误 因为

accept\u alert

方法仅在块完成预期后才预期模式

accept_alert('Hello world') do
  visit '/'
end
click_button 'Button'

---

自动接受（带有警告）意外警报的行为是由于其原始设计基于恶作剧，我认为目前不可配置。

谢谢，当我缩小

accept\u警报的范围时，它确实停止了自动接受（没有意识到包装两个命令会导致其行为不当）还有另外一个警报，我没想到现在这么解决了。我没有意识到是司机做的接受（但这是有道理的好），很高兴知道它是不可配置的，我不只是错过了一些东西。