如我们再次测试什么中所述。 来自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