ruby-on-rails - 什么不能在 Rails 中测试？

Question

我编写测试已经有一段时间了，我开始掌握一些窍门了。但是我有一些关于真正需要多少测试覆盖率的问题。共识似乎很明确:覆盖面越广越好。但是，至少从初学者的角度来看，我怀疑这是不是真的。

以这个完全普通的 Controller Action 为例:

def create
  @event = Event.new(params[:event])
  if @event.save
    flash[:notice] = "Event successfully created."
    redirect_to events_path
  else
    render :action => 'new'
  end
end

只是生成的脚手架。我们在这里没有做任何不寻常的事情。为什么为此操作编写 Controller 测试很重要？毕竟，我们甚至没有编写代码——生成器为我们完成了工作。除非 rails 中存在错误，否则这段代码应该没问题。似乎测试此操作与测试 collection_select 并没有太大区别 - 我们不会那样做。此外，假设我们使用的是 cucumber ，我们应该已经涵盖了基础知识(例如重定向的位置)。

对于简单的模型方法甚至可以这样说。例如:

def full_name
  "#{first_name} #{last_name}"
end

我们真的需要为如此简单的方法编写测试吗？如果存在语法错误，您将在页面刷新时发现它。同样，只要您的功能命中任何调用 full_name 方法的页面， cucumber 就会捕捉到这一点。显然，我们不应该依赖 cucumber 来处理任何太复杂的事情。但是 full_name 真的需要单元测试吗？

您可能会说，因为代码很简单，所以测试也会很简单。所以你不妨写一个测试，因为它只需要一分钟。但似乎编写本质上毫无值(value)的测试弊大于利。例如，它们会使您的规范困惑，使您更难专注于真正重要的复杂测试。此外，它们需要时间来运行(尽管可能不多)。

但是，正如我所说，我算不上专家测试员。我不一定提倡减少测试覆盖率。相反，我正在寻找一些专家建议。编写如此简单的测试真的有充分的理由吗？

Answer 1

我在这方面的经验是，您不应该浪费时间为微不足道的代码编写测试，除非您有很多复杂的东西依赖于正确性那些琐碎的事。一方面，我认为测试诸如 getter 和 setter 之类的东西完全是浪费时间，但我确信会有不止一个报道迷愿意在这方面反对我。

对我来说，测试有利于三件事:

1. 他们保证不破坏旧功能 如果我可以检查 我放入的新东西没有坏掉 我的旧东西通过运行测试，它是 一件好事。

2. 当我重写旧东西时，它们让我感到安全 我的代码 重构很少是微不足道的 一。但是，如果我想重构 不平凡的代码，有测试 确保我的重构没有 打破任何行为都是必须的。

3. 它们是我工作的文档 重要的代码需要 记录在案。但是，如果您同意 我认为代码中的注释是 魔鬼的工作，具有清晰和 简洁的单元测试，让你 了解什么是正确的行为 某事的(再次)是必须的。

任何我确定不会破坏的东西，或者我觉得不需要记录的东西，我都不会浪费时间进行测试。那么，您生成的 Controller 和模型方法，我会说即使没有单元测试也都很好。