RSpec 和 Open-URI 如何模拟引发 SocketError/TimeoutError
我希望能够指定当 Open-Uri open() 调用超时或引发异常(例如 SocketError)时,我正在按预期处理事情,但是我遇到了麻烦。
这是我的规范(针对 SocketError):
@obj.should_receive(:open).with("some_url").and_raise(SocketError)
以及我使用 open-uri 的对象部分:
begin
resp = open(url)
resp = resp.read
rescue SocketError
something = true
end
但是在这种情况下,规范会失败,并出现 nil.read
错误。
这是本周我第二次遇到这个问题,上一次我试图在用 timeout() {}
open() 时模拟 TimeoutError >,那一次我放弃了,只是通过开放课程导致了实际的超时。 我显然可以通过尝试调用无效的 URL 来引发 SocketError,但我确信有一种正确的方法可以使用 RSpec 来模拟它。
更新:我显然没有在深夜思考清楚,错误实际上是当我在 SocketError 之后重新尝试 URL 时, and_raise(SocketError) 部分工作正常。
I want to be able to spec out that when Open-Uri open() calls either timeout or raise an exception such as SocketError I am handling things as expected, however I'm having trouble with this.
Here is my spec (for SocketError):
@obj.should_receive(:open).with("some_url").and_raise(SocketError)
And the part of my object where I'm using open-uri:
begin
resp = open(url)
resp = resp.read
rescue SocketError
something = true
end
However in this situation the spec fails as with a nil.read
error.
This is the second time this week I've come across this problem, the previous time I was attempting to simulate a TimeoutError when wrapping open()
with a timeout() {}
, that time I gave up and just caused an actual timeout to happen by opening up the class. I could obviously cause this to throw a SocketError by trying to call an invalid URL, but I'm sure there is a correct way to mock this out with RSpec.
Update: I obviously wasn't thinking clearly that late at night, the error was actually when I re-tried the URL after the SocketError, the and_raise(SocketError) part worked fine.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
根据您提供的信息,您提供的行应该可以工作:我制作了一个小型测试类和规范(见下文),仅包含所描述的功能,并且事情的行为符合预期。 如果您可以提供更多上下文,这可能会有所帮助 - 例如,规范中的完整“it”块可能会暴露一些其他问题。
如前所述,以下规范通过了,我相信它捕获了您试图验证的逻辑:
The line you provided should work, based on the information you've given: I made a tiny test class and spec (see below) with only the described functionality, and things behaved as expected. It might be helpful if you could provide a little more context - the full "it" block from the spec, for instance, might expose some other problem.
As mentioned, the following spec passes, and I believe it captures the logic you were attempting to verify: