testing - 在持续集成中运行的测试中应该如何设置功能切换？

Question

使用功能切换时如何进行测试？您希望您的开发计算机尽可能接近生产环境。从我观看的视频来看，功能切换的实现方式允许某些人“使用”该功能(即 0 到 100% 的用户或选定的用户等)。

要正确地进行持续集成，您是否必须在测试时使用与生产服务器相同的功能切换设置？或者更好的是，如果该功能未在生产中关闭，请确保在构建管道中运行自动化测试时它已打开？您最终是在测试代码中添加功能开关，还是在新文件中编写测试？新功能何时是系统测试必须发生的过程中的强制性步骤？

Answer 1

在经常使用功能切换的多人团队中，对所有切换进行组合测试甚至计划对预期交互的切换组合进行测试是不切实际的。测试切换代码的​​实用策略必须适用于单个切换，而不考虑其他切换的状态。我已经看到以下过程运行良好:

• 因为我们会尽快将所有代码转移到生产环境中，所以当最初将切换引入项目时，会编写新测试以覆盖切换打开时的所有切换代码。因为我们进行了彻底的测试，所以关闭切换的代码的测试已经存在；这些测试已更改，以便切换明确关闭。只要有必要，可以在切换后开发切换代码。

• 在生产中打开切换之前，所有测试(不仅是切换代码的​​测试，还有应用程序的整个测试套件)都在切换打开的情况下运行。这会捕获由于与其他功能的不可预见的交互而导致的任何损坏。

• 切换在生产中打开

• 切换从代码中删除(连同任何仅在切换关闭时处于事件状态的代码)并将代码部署到生产环境

此过程既适用于切换仅隐藏全新功能的情况(因此没有代码仅在切换关闭时运行)以及切换在两个或多个版本的代码之间进行选择的情况，例如拆分测试。

回答几个具体问题:

• 不同切换状态的测试是放在同一个文件中还是不同的文件中取决于切换功能的大小。如果更改很小，将两个版本保存在同一个文件中是最简单的方法。如果它是对主要功能的完全重写，那么将一个或多个新的测试文件专门用于切换的新状态可能会更容易。受切换影响的文件数量还取决于您的测试架构。例如，在使用 RSpec 和 Cucumber 的 Rails 项目中，切换可能需要在 Cucumber 功能(验收/集成测试)、路由规范、 Controller 规范和模型规范中进行新测试，并且再次在每个级别测试切换可能位于同一文件或不同文件中，具体取决于切换功能的大小。

• 我认为“系统测试”是指手动测试。我宁愿没有那些。相反，我会自动执行所有测试，包括验收测试，所以我上面写的内容适用于所有测试。撇开这一点不谈，当我们在生产中打开切换之前运行所有测试时，切换的新状态暂时成为法律，然后当我们移除切换时永久成为法律。