接上一篇：Rails模式的实际应用--第二部分：Views（一）

对Movie的描述我们不会再增加新的行为，这使得我们的实现成为了一个简单的委托。

  委托的另一种实现方式，可以利用Ruby的Forwardable 模块。示例里面我们没有用这个方法是因为这里我们只需要委托一种方法。当需要委托很多方法的时候，Forwardable 会有很大的优势。

  MoviePresenter的全部代码和测试在GitHub上面都能够找得到。

放在一起

  我们现在有了一个可以放在Controller里面用的Presenter。因此，我们先添加一个测试去反馈一下我们确实有了一个Presenter。

  为了使得测试通过，我们把Controller里面的代码改成了如下：

  现在view不知道如何格式化一个发布日期和标题了。它只是简单的显示它获取到的东西。

展示一个Movie列表

  我们一起看看Movie列表。下面的代码展示了controller的测试和view的代码。

如果这个一定有效，一个设计的问题就是view一直延伸到了一个模型类，这使得view直接和数据库联系到一起了。一个提升的方式就是，引入一个供view使用用来遍可用的movie的变量。

跟旧版本相比，这是一个小的提升，但是却仍有一些问题。既然我们以实例变量的形式引入了一个抽象对象，如果我们要把@movie改名为@all_movie会怎么样呢？Controller的测试验证出那个变量的存在并且捕获它。因为不能够测试所有的真实行为，因而不是一个理想的测试，但是却是一个小的安全网。我们不知道view是否使用了正确的变量。这样我们会得到一个绿色的测试套件，但是却是坏掉的应用程序。只用通过手动再次测试view，我们才能捕捉到那个bug。

测试views？

  前面说的问题是一个常见的问题。这个问题不是Rails本身的问题，但是却在我们做UI测试的时候时常遇见。有很多方法可以解决这个问题，我们将讨论两种可能的选择。

  我们刚刚见过一个方法可以解决这个问题：验证一个实例变量的存在。正如前面所说，这个方法不能完全知道我们预防重命名变量的问题（甚至view代码里面的一个错字）。这样的测试只能验证view能用的东西是可用的，他们不会确认view是否实际使用了它。

  另一个方法是在测试中真实的构建view。用这种方法，我们可以验证模板可以没有错误的被构建。Rails（尤其是rspec-rails）有一个辅助方法叫做render_views。调用这个方法会导致测试的controller尝试去创建将要被发送到客户端的最终的view。

  用这种方法，我们可以写一个测试，每当view被创建失败的时候，测试就会执行失败。例如，因为一个变量没有被初始化。

  但是取决于views的大小，这个方法也会有一些弊端：构建真实的view拉低我们测试的执行速度。但值得一提的是，增加的测试套件的可靠性是值得我们花时间去运行它的。

  两种方法都是可行的选择，但是具体使用哪个取决于手上的案例的不同。一个比较好的中间立场大概就是，运用render_views去测试一部分内容，确保所有的东西都是正确连接的，而其他部分则是去测试controller而不用渲染views。

  测试运行时间和测试套件的可靠性之间是相互制约的，我们需要权衡选择。至于如何权衡，需要我们基于不同的实际案例进行讨论和决定。

【英文原文：https://8thlight.com/blog/christoph-gockel/2016/10/26/getting-rails-on-track-part-2-views.html】

{测试窝原创译文，译者：周婷婷}