在持续集成中运行的测试中应如何设置功能切换？ [英] How should feature toggles be set in tests run in continuous integration?

问题描述

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

How does one go about testing when using feature toggles? You want your development computer to be as close to production as possible. From videos I watched, feature toggles are implemented in a way to allow certain people to "use" the feature (i.e., 0 to 100 % of users, or selected users, etc.).

要正确地进行持续集成，在测试时是否需要使用与生产服务器相同的功能切换设置？或者更好的是，如果该功能尚未停止生产，请确保在构建管道中运行自动化测试时该功能已启用？您最终将功能切换项放入测试代码中还是将测试编写到新文件中？新功能何时是系统测试必须执行的过程中的必需步骤？

To do continuous integration correctly, would you have to use the same feature toggle settings as the production servers when it comes to testing? Or better yet, if the feature is not off on production, make sure it's on when it comes to running automated tests in the build pipeline? Do you end up putting feature toggles in your testing code, or write tests in a new file? When is the new feature a mandatory step in a process that must occur for system tests?

推荐答案

很少使用例行功能切换的人，对所有切换进行组合测试，甚至计划对预期会相互作用的切换组合进行测试都是不切实际的。测试切换代码的​​实用策略必须适用于单个切换，而无需考虑其他切换的状态。我已经看到以下过程运行良好：

In a team of more than a few people that uses feature toggles routinely, it's impractical to do combinatorial testing of all toggles or even to plan testing of combinations of toggles that are expected to interact. A practical strategy for testing toggled code has to work for a single toggle without considering the states of the other toggles. I've seen the following process work fairly well:

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

• Because we move all code to production as soon as possible, when a toggle is initially introduced into a project, new tests are written to cover all toggled code with the toggle on. Because we test thoroughly, tests for that code with the toggle off already exist; those tests are changed so that the toggle is explicitly off. Toggled code can be developed behind the toggle as long as is necessary.

在生产中打开切换器之前，立即进行所有测试（不仅限于测试）。切换后的代码，但应用程序的整个测试套件都在切换后运行。

Immediately before the toggle is turned on in production, all tests (not just the tests of the toggled code, but the application's entire test suite) are run with the toggle on. This catches any breakage due to unforeseen interactions with other features.

在生产中启用了切换开关

The toggle is turned on in production

将切换器从代码中删除（以及仅在关闭切换器时才激活的任何代码），并将代码部署到生产环境

The toggle is removed from the code (along with any code that is active only when the toggle is off) and the code is deployed to production

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

This process applies both to cases where a toggle only hides completely new functionality (so that there is no code that runs only when the toggle is off) and to cases where a toggle selects between two or more versions of the code, like a split test.

回答几个特定问题：

• 不同切换状态的测试是在同一个文件中还是在不同文件中进行，取决于切换功能的大小。如果更改很小，则将两个版本保存在同一文件中是最容易的。如果要完全重写一项主要功能，则将一个或多个新的测试文件专门用于切换的新状态可能会更容易。受切换影响的文件数量还取决于您的测试体系结构。例如，在使用RSpec和Cucumber的Rails项目中，切换可能需要在Cucumber功能中进行新的测试（接受/集成测试），路由规格，控制器规格和模型规格，并且同样，每个级别上的切换测试都可能

• Whether the tests of different toggled states go in the same file or a different file depends on the size of the toggled feature. If it's a small change, it's easiest to keep both versions in the same file. If it's a complete rewrite of a major feature, it's probably easier to have one or more new test files devoted to the new state of the toggle. The number of files affected by the toggle also depends on your test architecture. For example, in a Rails project that uses RSpec and Cucumber a toggle might require new tests in Cucumber features (acceptance/integration tests), routing specs, controller specs, and model specs, and, again, tests of the toggle at each level might be in the same file or a different file depending on the size of the toggled feature.

通过系统测试，我认为您的意思是手动测试。我更喜欢没有那些。相反，我将所有测试（包括验收测试）自动化，因此我在上面编写的内容适用于所有测试。抛开这一点，在我们在生产环境中将其打开之前运行所有测试并在打开该开关之前，该开关的新状态暂时变为法律，然后在移除该开关时永久变为新状态。

By "system tests" I think you mean manual tests. I prefer to not have those. Instead, I automate all tests, including acceptance tests, so what I wrote above applies to all tests. Leaving that aside, the new state of the toggle becomes law once temporarily when we run all the tests with the toggle on before turning it on in production, and then permanently when we remove the toggle.

这篇关于在持续集成中运行的测试中应如何设置功能切换？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！