【问题标题】:VCR Sharing requests between cassettes?录像带之间的 VCR 共享请求?
【发布时间】:2023-03-09 16:16:01
【问题描述】:

我的录像机配置是:

VCR.configure do |c|
  c.configure_rspec_metadata!
  c.cassette_library_dir = 'spec/cassettes'
  c.hook_into :webmock
  c.ignore_localhost = true
end

一个测试例子是:

it "creates a build", :vcr => {:cassette_name => "build/feature/create"} do
  visit new_build_path(build)

  fill_in("build_name", :with => "Test Build")
  click_button("Create Build")

  build = Build.first

  page.should have_content("Build was successfully created.")

  current_path.should == build_path(hub)
end

在运行此测试时,它会调用多个第 3 方 API,这些 API 会通过 VCR 记录这些请求。我遇到的问题是,VCR 在运行时似乎正在使用来自其他磁带的请求,这导致某些测试出现间歇性故障。我检查了磁带,有时(取决于顺序是如何显示的)所有请求都会被完美地记录和播放。值得注意的是,当整个套件运行时,它们总是在自己运行时工作。我不会在失败的规范之间共享卡带,唯一共享的是对 API 的一些常见请求,我强制对卡带命名以确保它使用正确的卡带。我希望这是有道理的......

我的主要问题是什么会导致这个问题?当使用record => :new_episodes 时,测试也能完美运行,但在使用record => :once 模式时就不行了。考虑到这种情况,这可能没问题,但我想确保我不会创建不必要的请求,并且据我了解,record => :once 应该可以工作,因为每个规范的请求都应该被隔离。

我知道如果没有更多信息,这可能很难回答,因此请告诉我是否有帮助。提前致谢!

【问题讨论】:

  • 那是什么?水豚?
  • 是的,我正在使用 capybara 和 poltergeist 驱动程序进行基于 JS 的测试
  • 您需要提及并正确标记您的问题,否则您将不会得到很好的回应。

标签: ruby-on-rails ruby capybara vcr poltergeist


【解决方案1】:

正如你所说,从你提供的一点点信息中很难回答。不过,我可以提供一些帮助解决问题的建议。

  • 您提到您正在使用 capybara JS 驱动程序。 Capybara 的 JS 驱动程序是异步的,这意味着您的测试线程可能会在您的应用程序处理特定请求之前继续运行 - 因此,如果测试脚本继续运行并弹出或插入新的 VCR 磁带,然后您的应用程序会发出 HTTP 请求 - - 它可能导致竞争条件。
  • VCR 有一个debug_logger 选项,可以让您深入了解VCR 正在做什么。它可能会回答您的问题。

祝你好运!

【讨论】:

  • 迈伦,谢谢你的建议。现在更奇怪的是,我已将问题隔离到一个没有 JS 测试的规范文件中。使用盒式 B 的规范 B 是否有可能使用规范 A 的盒式 A 的请求?我的理解是它不应该是这样,但从 debug_logger 和行为看来是这样。再澄清一点,运行 spec a 本身每次都会记录正确的请求,但是运行 spec a + spec b 会导致 spec b 错过一些在 spec a 中重新编码的请求。如果有更多信息可以帮助我知道。谢谢!
  • "使用盒 B 的规范 B 是否有可能使用规范 A 的盒 A 的请求?"我想一切皆有可能(毕竟软件很复杂),但鉴于 VCR 的工作原理,我无法想象这会如何发生。每个盒式磁带本质上是一个与其他盒式磁带隔离的沙箱。有一个例外:您可以嵌套盒式磁带,如果请求与内部盒式磁带不匹配,它将在外部盒式磁带中查找响应。所以,如果磁带没有从规格 A 中弹出,我猜可能会导致这种行为。
  • 更新:在查看调试记录器时,我注意到一个更奇怪的事情是,当 Spec A + Spec B 运行时,我认为之前共享的请求实际上并没有发出(或者至少没有被捕获)如果是,则由 VCR,我不认为是这种情况)但是当单独运行 Spec B 时,会发出请求...在录制磁带后运行它被请求,因此 VCR 抛出未处理的请求错误。我对这个不知所措哈哈......
  • 这表明这不是 VCR 问题,而是全局状态泄漏问题——例如一个规范更改了一些全局状态,从而触发了另一个规范中的额外 HTTP 请求,但是当另一个规范独立运行时,第一个规范没有更改全局状态,从而导致了这个问题。
  • Myron,我认为你是对的,事实证明这根本不像是 VCR 问题。当单独运行这些请求时,进一步研究它并通过控制台观察 http 请求,并且彼此紧随其后,肯定会保存一个状态。感谢您的所有帮助,顺便说一句,VCR 很棒!
猜你喜欢
  • 2013-12-10
  • 1970-01-01
  • 1970-01-01
  • 2013-04-12
  • 2014-03-23
  • 1970-01-01
  • 1970-01-01
  • 2015-11-03
  • 1970-01-01
相关资源
最近更新 更多