测试中的名称参数？

如我们再次测试什么中所述。 来自Test Smells的帮助 ，使测试代码解释其测试用例和测试数据是至关重要的责任。

编写测试代码时，最好的建议是着重于理解，而不是DRY代码。 这主要是因为重构测试要求我们将方法或命名常量隐藏在东西后面，这通常会使读者不了解这些名字后面的含义。

示例中使用的数字通常比名称更透明：

 assertThat(timeCalculator.isLater(EARLIER_TIME, LATER_TIME)) 
     .isTrue(); 

上面的示例类型记录了所使用的较早/较晚的时间值，但是如果满足以下条件，则可能会更容易理解：

 assertThat(timeCalculator.isLater( "12:00" , "12:01" )) 
     .isTrue(); 

这有助于读者了解确切的用例。

明确说明

测试名称是一个不错的选择：

 @Test  void aTimeOneMinuteLaterIsLater() { 
    ...  } 

通过上面的内容，我们可能更少地依赖于在代码中看到确切的测试数据。

您必须从两方面看。 我们绝对需要：

• 用例的好名字
• 透明测试数据

如果我们开始将测试数据隐藏在标签后面，它将开始破坏标签。 但是，如果我们正在编写许多示例怎么办？ 我们如何避免使用显式测试数据创建大量相同的测试函数，以使测试函数的名称可以解释测试用例？

参数化测试中的命名

我们需要将参数化测试视为输入和输出表，这些输入和输出通过系统中组件的示例定义规范。 核心测试功能几乎在做同样的事情：输入具体的测试数据并检查结果。 通过将其制成表格并具有通用功能，我们使测试变得更加丰富，但是命名又是什么呢？

有几种选择：

• 命名一些常量，并使用它们来填充输入值的数组–如果名称很好，则代码阅读者可以看到用例
• 在输入的每一行旁边添加一条注释，以解释用例–同样，这对于测试代码的读者来说也很不错
• 在输入行中添加描述用例的字符串值–在代码检查时和测试执行/报告时都可见

在这些方法中，如果测试真的很简单，建议不要使用它们。 如果我们有几个完全相同的用例的示例，那么一个名称和数据将很容易解释。 如果我们有多个用相同的断言机制表达的用例，则添加一个文档字段，并丰富测试以在测试名称中显示它，或在断言失败中提及它，将有助于在测试失败时诊断问题，并有助于将来的测试读者/维护者。

这里没有完美的答案，但我希望这个讨论能帮助您确定最适合您的方法。

翻译自: https://www.javacodegeeks.com/2019/11/name-parameters-in-tests.html