自动化测试设计原则可读性_测试属性2：可读性

自动化测试设计原则可读性

这是关于测试属性的第二篇文章，在现在著名的“ 如何测试您的测试 ”文章中进行了介绍。

我们通常会忘记从测试中获得的大部分价值是在编写它们之后获得的。 当然，TDD可以帮助设计代码，但是让我们面对现实吧，当所有事情第一次正常运行时，我们的测试就会成为我们代码的未来守护者。 一旦就位，我们就可以更改代码，希望它变得更好，因为它知道一切仍然有效。

但是，如果（以及何时）发生故障，则需要完成工作。 我们需要了解以前没有起作用的东西。 然后，我们需要分析这种情况：根据我们现在正在做的事情，是否应该解决此问题？ 还是我们现在需要用新的测试来覆盖这项新功能，而抛弃旧的功能呢？ 最后，根据我们的分析结果，再次进行编码和测试。

我们在时间上走得越远，测试和代码就会变得陈旧。 然后我们完全忘记它们。 更改的成本增加。 分析阶段变得更长，因为我们需要重新了解周围的环境。 我们需要重新学习哪些仍然有效，哪些停止有效。 即使我们知道，我们也不记得哪些更改会导致副作用，以及这些副作用将如何解决。

有效的测试可最小化此过程。 它们需要可读性。

可读性是主观的。 我现在发现的（在我写完之后立即）可读的内容在6个月内似乎不再那么可读。 更别说别人了。

因此，与其尝试定义测试的可读性，不如将其分解为我们关注并可以评估的元素。

什么名字

测试的最重要部分（除了测试正确的事物之外 ）是它的名称。 原因很简单：测试失败时，名称是测试失败时首先看到的名称。 这是我们得到第一个线索，表明出了点问题，因此，它需要尽可能多地告诉我们。

测试的名称应包括（至少）特定情况和测试的预期结果。 如果我们正在测试API，也应该这样说。

例如：

@Test public void divideCounterBy5Is25() { ...

我可以理解测试的作用（关于将Counter除以除法的场景），详细信息（除以5）和该场景的预期结果（25）。

如果听起来像一个句子，那就更好了。 好名字来自口头描述它们。

无论您使用大写字母，下划线或任何其他内容都无关紧要。 使用与团队一致的约定很重要。

名称也应足够具体，以在精神上区别于其他同级测验。 因此，在我们的示例中：

@Test public void divideCounterBy0Throws() { ...

由于前缀相似，因此此测试与名字足够相似，可以将其标识为“同级”情况。 具体情况和结果是不同的。 这很重要，因为当这两个一起出现在测试运行程序中时，一个失败而一个没有失败，这有助于我们在甚至开始调试之前就找出问题所在。 这些是解决问题的线索。

什么身体

如果我们的名字不能帮助您找到问题所在，则测试机构应填补空白。 它应包含了解方案所需的所有信息。

以下是使测试代码可读的一些技巧：

• 测试应该简短。 大约短10-15行。
• 如果设置很长，请将其解压缩为具有描述性名称的函数。
• 避免使用预测试功能，例如JUnit的@Before或MSTest [TestInitialize]。 而是使用直接从测试中调用的方法。 当您查看代码时，需要看到设置和拆解，否则，您将需要进一步搜索，并假设更多内容。 使用设置方法调试测试也不会很有趣，因为在特定的环境中输入测试可能会让您感到惊讶。
• 避免使用基本测试类。 它们也隐藏了与理解场景有关的信息。 在这里，优先于继承而不是组成。
• 使断言部分脱颖而出。
• 确保正文和名称对齐。

分析需要时间，最差的（也是最慢的）分析需要调试。 测试（和代码）应具有足够的可读性，以帮助我们绕开这个浪费的过程 。

几分钟内更好的可读性

我们有偏见，因此认为我们编写的代码和测试是如此出色，每个人都可以理解。 我们常常错了。

在敏捷中，反馈就是答案。

使用“第三只耳朵的法则”。 抓住一个毫不怀疑的同事的耳朵，将其拉近屏幕，她可以告诉您是否了解测试的目的。

更好的是，在编写测试时配对。 反馈会给我们一个副产品，您会得到更好的测试。

无论您做什么，都不要将其留待以后使用。 如果不需要，不要使用暴力。

现在使测试更具可读性，以便稍后阅读。

翻译自: https://www.javacodegeeks.com/2014/07/test-attribute-2-readability.html

自动化测试设计原则可读性