ruby-on-rails - 如何确保我正在测试所有内容，我拥有所有功能并且只有旧代码的那些功能？

Question

我们正在运行一个相当大的网站，我们有一些我们希望很好地覆盖的关键遗留代码。

与此同时，我们希望收到一份关于我们目前支持和涵盖的功能的报告。而且我们还想确保我们真正涵盖了所有可能的极端情况。一些代码路径很关键，即使在达到 100% 覆盖率后仍需要进行更多测试。

由于我们已经在使用 rspec 并且 rspec 具有“feature”和“scenario”关键字，因此我们尝试使用 rspec 创建一个列表而不是使用 cucumber，但我认为这个问题可以应用于任何测试工具。

我们想要这样的东西:

feature "each advertisement will be shown a specified % of impressions" 
  scenario "As ..." 

从管理人员的角度来看，此功能很小，但在代码中却很大。它涉及后端工具、周期性任务、模型中的逻辑以及后端和前端的 View 。我们试着这样划分:

feature "each creative will be shown a specified % of impressions" 
   context "configuration"
     context "display"
      scenario "..."
     context "models"
      it "should ..."
   context "frontend"
    context "display"
      scenario "..."
    context "models"
      it "should ..."

配置在另一个工具中进行，显示将包含集成测试，模型将包含单元测试。

我重复一遍，但我的想法是确保该功能真正完成(包括构建配置工具)并经过 100% 测试。

但是看这个文件，它既不是集成，也不是单元测试，甚至不属于任何特定项目。绝对应该有更好的方法来管理它。

您可以分享任何经验、资源和想法来指导我们吗？

Answer 1

您描述的场景是 BDD 如此受欢迎的一个重要原因。它迫使您以易于测试的方式编写代码。话虽如此，您显然不会返回并重写整个遗留应用程序。不过，您应该考虑以下几点:

• 在浏览应用程序的每个部分时，您应该问自己“重构是否比为此编写测试更难？”。有时无法避免在编写测试之前进行重构。
• 测试不是关于 100% 的覆盖率，而是关于 100% 的置信度。正如您所提到的，即使覆盖率达到 100%，您仍计划编写更多测试。这是因为你是为了自信。一旦您对一段代码充满信心，就继续前进。您随时可以稍后再回来查看它。
• 根据我的经验，Cucumber 对于涵盖大部分应用程序的测试来说更容易。我认为这样做的原因是用简单的英语写出测试会让你想到你不会想到的东西。它还可以让您专注于行为而不是代码，并且可以使重构成为一项不那么令人生畏的任务。
• 如果您不再接触该代码，那么向现有代码添加测试并不会真正让您受益匪浅。首先测试您要更改(即重构)的代码。

我也推荐这本书Rails Test Prescriptions ，特别是最后一章中的“测试遗留应用程序”。