如何使用RSpec测试Rails应用程序以获得完整的测试覆盖率？

Question

当为一个简单的Rails应用程序编写规范时，下面的方法是否是完整测试覆盖率的正确方法？

1. 为所有用户故事编写功能规范
2. 编写控制器规范，以确保单个动作响应是正确的，并设置所有必需的变量。
3. 编写模型规范以确保所有方法，验证，e tc。正在按计划工作
4. 写邮件规范
5. 写入路由规格

这是否足够，太多(例如，如果我编写了特性规范，我可以跳过一些低级规范)，还是不够？为什么？

Answer 1

您不需要为每个层中的每个对象编写规范来获得100%的测试覆盖率或测试驱动(要求您实现)应用程序中的所有重要行为。相反，正如行为驱动开发(BDD)所建议的那样，在外部编写规范，只在必要时编写低级规范。

测试完整性的最重要的衡量标准是需求覆盖:它有助于每个用户故事，以及每个需要新代码的故事的每个细节，至少要用一个测试来表示。如果您正在遵循典型的敏捷实践(提到用户故事表明您是敏捷实践)，那么您的测试可能是记录需求的唯一地方，因此您可能无法在这种覆盖率上提供一个数字。它也是有益的

• 行覆盖(大多数人说测试覆盖率时的意思)，这意味着每一行代码至少由一个测试来执行，并且
• 集成覆盖率，这意味着从一个类到另一个类的每个方法调用至少由一个测试来执行。

每一个故事，

• 只写功能规格，将测试-驱动所有不同的故事的幸福道路。
• 编写额外的特性规范，以确保集成覆盖架构上有趣的愉快路径和悲伤路径的细微变化。例如，我经常为涉及表单的故事编写三种特性规范:一种是用户填写每个可能的字段并成功，另一种是用户尽可能少地填写信息并仍然成功(确保未指定的值和默认值按预期工作)，以及用户犯错误、失败、纠正错误并成功的情况。

此时，您已经测试了每个层(控制器、模型、视图、帮助程序、邮件程序等)。已经存在了，只有特征规格。

• 编写模型和助手规范，以驱逐出完全存在于这些类中的详细需求。例如，一旦您编写了一个悲伤路径特性规范，该规范确定输入一个特定的无效属性将用户发送回编辑其表单提交并显示一条消息，则可以完全通过在该模型的规范中编写更多示例来处理其他无效属性，该规范测试模型属性是否被验证，并让您已经测试过的体系结构将错误传播回用户。 请注意，虽然您的特性规范已经通过模型和助手方法测试了快乐路径，但一旦您开始为一个方法编写用于次要或错误情况的示例，您可能也想要为该方法编写一个或多个示例，这样您就可以在一个地方看到该方法的全部描述，这样您就可以通过运行该方法的所有示例来全面测试该方法，而不必运行任何特性规范。

您可能根本不需要某种规格：

• 考虑因素充分的控制器动作很短，几乎没有条件，所以您通常根本不需要任何控制器规范。只在需要时编写它们，并将模型、mailer等行为存根出来，以保持它们的简单和快速。
• 类似地，视图和邮件程序应该很少或没有条件(应该将复杂的代码重构到帮助器和模型方法中)，因此您通常根本不需要视图或邮件规范。
• 您的功能规格将有测试驱动的所有路线，你需要，所以你可能不需要路由规格。当我不得不对路由进行重大重构时，我才会使用路由规范，比如从一个主要版本的Rails升级到下一个版本。

只要您总是在编写新代码之前编写测试，您将始终拥有100%的行覆盖率。

Answer 2

这个测试策略听起来很全面。如果所有这些测试都已经就绪，那么您就有了很好的测试覆盖率。然而，交付项目需要更长的时间。你也不会像做更有限的测试的人那样敏捷。测试必须适合这个项目。不要过度测试。过度测试会耗费时间和金钱。别受考验。接受测试会耗费时间和金钱。

有正确的方法来进行单元测试。有正确的方法来进行集成测试。手套必须要合身。如果您的应用程序主要是面向前端的，那么最好从集成测试开始。如果您编写后端应用程序或API，那么单元测试可能是一个更好的起点。我认为接近一种测试风格，然后扩展到不同的风格是一个更好的开始，而不是尝试和测试您的应用程序的每一层。

为什么不从简单的单元测试开始呢？它们很容易写。编写这些测试，然后跟踪您发送的bug数量。你让太多虫子进来了吗？你有很多回归问题吗？是否有您的套件没有发现的bug正在进入生产过程？如果答案是肯定的，那么也许是时候写一些更高水平的测试了。记住，测试越高，开发成本就越高。

如果您没有发布错误，那么您就没有理由编写更多的测试。记住这里的最终目标。我们想要发送没有bug的代码。如果我们可以编写一个测试和一个单独的测试，以确保我们正在这样做，那么就没有理由进一步测试了。