Question

我们正在运行一个非常大的网站，我们有一些我们想要覆盖的关键遗留代码。

与此同时，我们希望报告我们目前支持和涵盖的功能。而且我们也希望确保我们真正涵盖所有可能的角落案例。一些代码路径是关键的，即使达到100％的覆盖率，也需要更多的测试。

由于我们已经在使用rspec并且rspec具有“特征”和“场景”关键字，我们尝试使用rspec而不是黄瓜来制作列表，但我认为这个问题可以应用于任何测试工具。

我们想要这样的事情：

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

从管理人员的角度来看，这个功能很少，但代码却很多。它涉及后端工具，周期性任务，模型中的逻辑以及后端和前端的视图。我们试图将它分开：

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，特别是最后一章“测试遗留应用程序”。

如何确保我测试所有内容，我有所有功能，只有旧代码的功能？

1 个答案: