如何使用版本切换和验收测试驱动的开发？

Question

功能/发布切换的优点之一是您可以集成和部署代码，而不需要发布它。但ATDD是如何运作的呢？如果我编写了一些失败的测试，因为我还没有完成这些特性的实现，即使新的实现代码在切换后，我也不能很好地集成这些测试，对吗？否则CI管道将失败。

这是否意味着我应该在与实现相同的切换后进行测试？这样的话，当特性完成时，我可以翻转按钮，这将打开测试和相关的实现代码？

使用版本切换和ATDD的团队通常是如何做到的？

Answer 1

这是品味的问题。

基本上，是的，这是一个很好的方法。从技术上讲，您可以使用相同的切换，但您也可能更喜欢用于测试的独立切换，但是有一些映射，例如：

• 应用程序切换1A -测试开关1B
• 应用开关2A -测试开关2B
• 应用键3A -测试开关3B

因此，您可以完全控制测试，而不依赖于为应用程序设置的切换。例如，当应用程序切换禁用相应功能时，如果激活测试，您可能需要检查测试是否真的会失败。

此外，不仅可以对新功能进行新的测试。应用程序切换也意味着对现有功能的更改。因此，您可以决定不使用单独的测试，而是使用相同的测试并使用切换来控制测试的某些部分。同样，为了能够在固定的应用程序状态下用不同的切换独立地执行测试，您可能希望选择独立的测试切换。

Answer 2

应该编写测试，以便他们知道哪些切换需要打开(默认情况下，哪些应该关闭)，并将这些切换设置为测试设置的一部分。

至于CI，这些测试还不是回归测试。因此，它们不需要作为CI回归测试套件的一部分运行。因此，他们不应该“阻止”构建，但是您可能仍然希望运行进度测试，因此添加一个步骤来分别运行进度测试和回归测试，如果出现错误，则不会阻止。

构建如下所示：

  > Checkout
  > Build
  > Unit Test
  > Regression Test
  > In parallel
     > Progression Test
     > Package and deployment

你可以通过以下方式实现这一点：

• 标记进展测试，
• 或者通过标记回归测试，
• 或者通过对每一组测试进行分类，并告诉CI哪些类别是回归/进展。(非常简单地处理一个名为progression.txt的文本文件)