在软件开发人员抱怨单元测试的众多原因中，处理嘈杂的测试套件是最大的原因之一。而且，某个软件存在的时间越长，它的噪音就越大。
在软件开发人员抱怨单元测试的众多原因中，处理嘈杂的测试套件是最大的原因之一。而且，某个软件存在的时间越长，它的噪音就越大。
为了明确起见，“噪音”是指不断失败的测试，但是无论如何您都知道（认为）还可以，所以就顺其自然。或有时会失败且有时会起作用的测试，但没有人曾费心找出或修复它们。然后，由于代码已更改并且需要更新测试，因此某些测试确实失败了。所有这些噪音只是为了引起我们的注意而尖叫，但要注意的是，噪音越大，我们对它所做的任何有意义的事情就越不可能。
但猜猜怎么了些“失败但可以通过”的测试中的某个地方是您希望知道的一些实际问题。认为它就像尝试使用拼写检查器一样。如果您不坚持下去，将会得到您不关心的所有东西，例如特殊的行业用语，名称等，这些都不是真正的拼写问题。但是，隐藏在混乱中的某个地方却是您实际上犯下的令人尴尬的错误–您想要从那里出来的愚蠢的拼写错误的单词。当然，全球存在大量错误的拼写错误–但是与您的软件不同，那里并没有很多内在的风险，只是有些尴尬。
但是，单元测试套件通常处于相同状态。我们习惯于看到和忽略很多嘈杂的结果，不幸的是隐藏了我们需要知道和理解的真实结果。在许多组织中，要解决此问题，有人会不时安排一次冲刺以清理测试套件，时间间隔从几个月到几年。花费大量时间使套件尽可能人性化，但不可避免地问题很快就会回来，而且比您预期的要快。这会形成一个负面的反馈循环——没有人希望清理测试，因为他们认为下次会再次变得嘈杂。
答案是采用一种更实用的方法–从一开始就消除乏味，无用的清理冲刺，并避免使用嘈杂的测试套件。
尽量减少嘈杂的测试套件
为此，重要的是要了解单元测试失败时的含义。它归结为三个原因，并提供了简单的修复程序：
-
代码已损坏。因此，请修复代码。（理想情况下，这是干净的测试套件告诉您的内容。）
代码已正确更改，现在测试已中断。因此，请修复测试以匹配新代码。（如果您的代码正在更改，则可以预期会发生这种情况。在处理代码时，有充分的理由进行测试。）
测试是错误的，代码很好。因此，请修复测试。（或者删除它。但是关键是–不要忽略测试。）
现在。您可能在想–如果我的大量测试用例适合该第三类呢有什么帮助此，让我们分解一下。
产生噪声的原因通常归结为一些基本问题：不良测试，脆弱测试或不良主张。不良测试是指无法正常工作的测试。他们正在进行比他们应有的测试更多的东西，或者他们悬挂的数据不一致或可能因外部条件而发生变化。
为了将噪音降到最低，请确保对于每一个给您带来问题的测试（或者更好的是所有测试），您都能很好地回答以下两个简单问题：
-
测试通过意味着什么/p>
测试失败意味着什么/p>
如果对于任何测试，您对这两个问题都没有合理的答案，则需要改进。
改善脆弱性测试
易碎测试是那些容易打破的测试。同样，这通常是懒惰断言的征兆–仅检查事物（因为可以对其进行检查）并不意味着应该对其进行检查。每个断言应具有与要测试的代码满足的要求有关的真实含义。常见的罪魁祸首包括对日期/时间敏感的断言，操作系统依赖性，文件名/路径依赖性，第三方软件安装，合作伙伴API等。请确保您仅断言为进行良好测试所需的最低要求，并确保测试所需的一切都是源代码控制和构建系统的一部分。
其他错误的断言要么是持续处于故障状态，要么您不介意放开（“噢，别无所求，不要担心”），或者处于不断变化的状态（“以前很好，昨天失败了，但是今天很好！”）如果代码不断变化，可以在短时间内获得不断变化的结果，但是从长远来看，这是不可接受的。您需要了解为什么测试结果一直在变化，或者肯定为什么您认为可以失败并仍然可以发布。对单元测试（包括断言）进行同行评审将大大有助于永久解决此问题。（同行评审的另一个好处是果您处于合规环境中，测试是强制性监督的一部分，那么生存起来就容易得多。）
评估损坏的测试确实是进行大多数清理工作的好地方。我想请您认真检查失败了几个月甚至几年的测试。问问自己，他们是否真的在增值。记住，您还是会忽略结果，所以说实话它们有什么用除您忽略的测试将使您可以将精力集中在重要的测试上，并实际上提高了总体质量。
因此，它变得相当简单（尽管可能需要花费最初的时间）。要进行清理，只需遵循以下最佳实践：
-
定期运行测试，以确保它们不会过时——使用代码进行测试。
删除始终失败的测试，或对其进行修复。
删除不断翻转状态（通过/失败）或拧紧测试的测试。
同行评审单元测试。
当然，不要忘记使用自动化来完成繁琐的工作，从而使您花在编写测试上的时间更有效率，从而使您可以创建噪音较小的测试。
使用测试自动化
利用自动化软件测试的优势，可以减少单元测试的工作量。如果您可以让自动化完成简单繁琐的部分（计算机擅长的部分），那么您就可以腾出时间来做需要实际的人类智慧（您擅长的事情）的事情。例如，让自动化创建您的xUnit测试用例的第一个工作通过（做起来非常繁琐的简单代码）。如果让工具自动生成吸气剂/装甲剂测试方法，则可以节省大量时间，可用于其他更有趣的事情。
当我们对测试自动化变得更加复杂时，工具可以提供更多的帮助，进行单元测试中一些棘手的部分，例如创建和配置存根和模拟。您利用自动化的机会越多，单元测试所花费的时间就越少，也将减少很多乏味。如果您使用的是Java，请查看集成在Parasoft Jtest中的新的单元测试助手。它可以做所有这些事情，甚至更多，这使得单元测试不仅更加容易，而且更加令人愉悦。
标签：
来源：慧都
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！