Rails 3、RSpec 2.5：在命名范围中使用 should_receive 或 Stub_chain
我使用 Rails 3.0.4 和 RSpec 2.5。在我的控制器中，我大量使用命名范围，例如，
@collection = GuestbookEntry.nonreplies.bydate.inclusive.paginate(
:page => params[:page], :conditions => { ... })
在我的测试中，我希望能够模拟此类查询的结果，而不是措辞。我认为这样做是没有意义的，
GuestbookEntry.stub_chain(:nonreplies, :bydate, ...).and_return(...)
因为当我决定重新排序命名范围时，这个测试就会失败。
使用 Rails 2.3 和 RSpec 1.x，这工作得很好：我可以编写
GuestbookEntry.should_receive(:find).with(:all, :conditions => { ... })
并且上面的调用将被捕获并正确处理。然而，在 Rails 3 中，由于某种原因，这不再起作用了。
为什么？如何对嵌套范围的结果设置期望或存根？由于 Rails 3 的 ActiveModel 中的所有内容都是命名范围（感谢 ARel），因此这必须以某种方式实现，否则测试确实会非常脆弱。
谢谢！
更新：另请参阅GitHub 上的问题报告。
I use Rails 3.0.4 and RSpec 2.5. In my controllers I use named scopes heavily, for example
@collection = GuestbookEntry.nonreplies.bydate.inclusive.paginate(
:page => params[:page], :conditions => { ... })
In my tests, I want to be able to mock the result of such a query, not the wording. I do not think it makes sense to do something like
GuestbookEntry.stub_chain(:nonreplies, :bydate, ...).and_return(...)
because this test will fail the moment I decide to reorder the named scopes.
With Rails 2.3 and RSpec 1.x, this worked fine: I could write
GuestbookEntry.should_receive(:find).with(:all, :conditions => { ... })
and the above call would be caught and correctly handled. However, with Rails 3, for some reason this does not work any more.
Why? How do I set expectations or stubs on the result of nested scopes? Since everything in Rails 3's ActiveModel is a named scope (thanks to ARel), this must be possible somehow, or tests would indeed be very brittle.
Thanks!
Update: See also issue report on GitHub.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题也困扰了我一段时间！
我认为该行为与 Rails 2 不同的原因是因为在控制器中的变量分配期间不再执行查询。相反，它是根据需要延迟加载的。
我同意 Mark Wilden 的观点，即最好将所有这些范围包装在模型中更大的范围和规范中。该作用域显然具有特定的功能，因此就像规范调用多个其他方法的方法的行为一样，您也可以规范连接多个其他作用域的作用域的行为。
This problem has bugged me for a while too!
I believe the reason the behaviour is different from Rails 2 is because the query is no longer being performed during the variable assignment in the controller. Instead, it's lazy-loaded as required.
I agree with Mark Wilden that it's better to wrap all of these scopes in a larger scope and spec that in your model. This scope clearly has a specific function, so just as one would spec the behaviour of a method which calls several other methods, you would spec the behaviour of a scope that joins several other scopes.
我会将如此复杂的查询包装在其自己的范围内，并对其进行存根。
I would wrap such a complicated query in its own scope, and stub that.