是否可以有条件地打开或关闭特定的fitnesse测试？
在Fowler/Hodgson的术语中，我们使用"释放切换"，即允许在我们的测试和专业环境中禁用更改的切换，直到准备好进入黄金时段。我们不希望这些功能的故障影响向pro发货，因此对这些测试的结果不感兴趣。从这个意义上说，CDP管道一直将切换设置为"PRO"配置，以保持验收测试的快速和集中。那么，如何让fitnesse忽略与切换相关的测试呢？
我看到了这个相关的答案：在持续集成中运行的测试中，应该如何设置功能切换？这表明该用户测试了开关的所有侧面，但这通常对我们来说是不可能的——例如，假设一个功能由于DI或其他原因需要重新启动应用程序来更改切换(例如，因为该功能需要连接不同的网络控制器)——这对fitnesse来说是一件非常难做的事。这会导致测试速度缓慢，并且正在测试我们实际上不需要测试的功能。
因此，我们希望能够开发功能(在切换之后)、测试、固定装置(用相同的切换标记)，以及当我们准备好启用它们时，将它们弹开以在CI管道中运行。类似于：
- 决定功能需要切换，因此创建一个TOG123更改api行为
- 将切换添加到所有代码都能看到的中央切换系统
- 在CI环境的配置中将切换设置为"false">
- 开发切换代码背后的特性和适合性测试
- 准备CDP时设置为true
- 通过测试后，运送至专业
- 及时。。通过搜索TOG123并清理混乱来删除切换
我认为没有一个好的答案是如何在有条件的情况下保护特定的适合性测试(即，新测试将启用时间：TOG123.，旧测试将禁用时间：TOG123.)。适合性似乎有点。。我觉得很尴尬。标签是我要找的吗？套房似乎太宽了。。
根据您的描述，标签似乎是您想要的。它们允许您标记新功能的测试，并选择在执行的运行中包括或排除这些测试。
附带说明：如果这些功能是真正的"切换"，即它们可以在生产中启用，而不需要新版本，我建议测试切换的所有方面；否则，你不知道启用切换是否真的是一件好事/安全的事情。如果新功能预计不会"准备好生产"，因此不需要在部署前进行测试：为什么要在发布的产品版本中包含它们？在这种情况下，我建议您将这些新功能保留在一个单独的分支中，该分支尚未合并到开发/主分支中。然后，您可以在同一个存储库中维护/开发这些功能的测试(或者类似的测试，如果测试在不同的存储库中)。这防止了生产中不应该使用的复杂性/代码，也避免了事后"清理混乱"的需要：清理是分支的一部分。合并分支时，会添加、测试新功能，现在过时的测试/代码会立即删除。当然，这确实需要基于分支运行/测试系统的能力，但这是在进行连续交付时所具备的。