让我们说我有一个非常复杂的视图，有一个非常复杂的测试规范。 我想为它添加另一个功能，我想用RSpec推动开发。
我想向Employee类添加联系人。
在employee.html.erb的某处，我添加了一行：
#lots of data rendered so far
<%= render @employee.contacts %>
#even more here
目前我还不太了解_contact.html.erb部分需要的样子。要直接从我的员工主视图规范show.html.erb_spec.rb来测试它，我将不得不做很多设置填充或模拟不同的数据库员工是从（项目，部门等）构建。
我现在需要测试的是，部分，我不关心这个员工目前所属的部门，项目和其他事情，我不想花时间嘲笑他们。我稍后可能会将它添加到我的主要规范中，并创建测试整个视图所需的一切，但不仅仅是喷射。
您是否有任何技术或方法来创建Employee实例，向其添加一些联系人，并仅针对部分测试视图？ 不必担心员工的所有其他事情。
更新IGEL答案：
我同意你的意见，并且测试期望（...）。接收（：render）对于请求规范是100％足够的，如果我已经有了部分模板，我就不会再进一步了。 我只是想走极端，通过RSpec驾驶我的div和跨越。不测试新功能的行为，但它看起来。你认为它不值得吗？
我根本没有测试视图（结构），但我看过一些像Rails Tutorial这样的文档，Michael不仅测试行为，还测试结构。我以为我会试一试:)
答案 0 :(得分：1)
正确的答案是避免非常复杂的观点。如果视图中几乎没有逻辑，那么可能没有必要对其进行测试。将逻辑提取到presenters，这样就可以更容易地进行测试。我没有用视图测试来测试我的观点，因为维护它们通常不是很有趣。一些功能规格在这里给了我足够的安全性。
如果您仍想测试它，您可能希望使用预期的参数调用render：
expect(view).to receive(:render).with(@employee.contacts)
不确定该视图是否可通过view获得。
PS：不要只是避免编写复杂的视图，避免复杂的代码。这真的很难，但绝对值得花时间。几乎每个开发人员都可以将可能正常工作的东西混在一起，但创建易于理解和改变的东西将有助于包括未来在内的所有人。代码的读取次数比写入/更改次数高十倍，因此我们必须对其进行优化。
我没有时间写一封短信，所以我写了一篇很长的短信。 - 马克吐温