单元测试已成为开发的标准部分。许多工具可以以许多不同的方式用于它。本文演示了一些提示，或者说，对我来说效果很好的最佳实践。
在本文中，您将了解
如何使用 JUnit 和 Assert 框架编写干净且可读的单元测试
在某些情况下如何避免假阳性测试
编写单元测试时应避免的事项
不要过度使用 NPE 检查
我们都倾向于在主代码中尽可能避免 NullPointerException，因为它可能会导致丑陋的后果。我相信我们主要关心的不是在测试中避免NPE。我们的目标是以干净、可读和可靠的方式验证被测组件的行为。
不良做法
过去很多次，即使不需要断言，我也使用过断言，如下例所示：isNotNull
@Test
public void getMessage() {
assertThat(service).isNotNull();
assertThat(service.getMessage()).isEqualTo("Hello world!");
}
此测试产生如下错误：
java.lang.AssertionError:
Expecting actual not to be null
at com.github.aha.poc.junit.spring.StandardSpringTest.test(StandardSpringTest.java:19)
良好做法
尽管附加断言并不真正有害，但由于以下原因，应避免使用：isNotNull
它不会增加任何附加值。它只是需要阅读和维护的更多代码。
无论如何，测试都会失败，我们看到了失败的真正根本原因。该测试仍然实现了其目的。servicenull
使用 AssertJ 断言时，生成的错误消息甚至更好。
请参阅下面修改后的测试断言。
@Test
public void getMessage() {
assertThat(service.getMessage()).isEqualTo("Hello world!");
}
修改后的测试会产生如下错误：
java.lang.NullPointerException: Cannot invoke "com.github.aha.poc.junit.spring.HelloService.getMessage()" because "this.service" is null
at com.github.aha.poc.junit.spring.StandardSpringTest.test(StandardSpringTest.java:19)
注意：该示例可以在 SimpleSpringTest 中找到。
断言值而不是结果
有时，我们会编写一个正确的测试，但以“糟糕”的方式。这意味着测试完全按预期工作并验证了我们的组件，但失败没有提供足够的信息。因此，我们的目标是断言价值而不是比较结果。
不良做法
让我们看看几个这样的糟糕测试：
// #1
assertThat(argument.contains("o")).isTrue();
// #2
var result = "Welcome to JDK 10";
assertThat(result instanceof String).isTrue();
// #3
assertThat("".isBlank()).isTrue();
// #4
Optional<Method> testMethod = testInfo.getTestMethod();
assertThat(testMethod.isPresent()).isTrue();
上述测试中的一些错误如下所示。
#1
Expecting value to be true but was false
at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502)
at com.github.aha.poc.junit5.params.SimpleParamTests.stringTest(SimpleParamTests.java:23)
#3
Expecting value to be true but was false
at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502)
at com.github.aha.poc.junit5.ConditionalTests.checkJdk11Feature(ConditionalTests.java:50)
良好做法
使用 AssertJ 及其流畅的 API 可以轻松解决问题。上面提到的所有情况都可以很容易地改写为：
// #1
assertThat(argument).contains("o");
// #2
assertThat(result).isInstanceOf(String.class);
// #3
assertThat("").isBlank();
// #4
assertThat(testMethod).isPresent();
与前面提到的完全相同的错误现在提供了更多价值。
#1
Expecting actual:
"Hello"
to contain:
"f"
at com.github.aha.poc.junit5.params.SimpleParamTests.stringTest(SimpleParamTests.java:23)
#3
Expecting blank but was: "a"
at com.github.aha.poc.junit5.ConditionalTests.checkJdk11Feature(ConditionalTests.java:50)
注意：该示例可以在 SimpleParamTests 中找到。
与组相关的断言在一起
断言链接和相关的代码缩进对测试的清晰度和可读性有很大帮助。
不良做法
当我们编写测试时，我们最终会得到正确但可读性较差的测试。让我们想象一个测试，我们想要在其中查找国家/地区并进行以下检查：
计算找到的国家/地区。
使用多个值断言第一个条目。
此类测试可能如下所示：
@Test
void listCountries() {
List<Country> result = ...;
assertThat(result).hasSize(5);
var country = result.get(0);
assertThat(country.getName()).isEqualTo("Spain");
assertThat(country.getCities().stream().map(City::getName)).contains("Barcelona");
良好做法
尽管前面的测试是正确的，但我们应该通过将相关断言组合在一起（第 9-11 行）来大大提高可读性。这里的目标是断言一次，并根据需要编写许多链接断言。请参阅下面的修改版本。result
@Test
void listCountries() {
List<Country> result = ...;
assertThat(result)
.hasSize(5)
.singleElement()
.satisfies(c -> {
assertThat(c.getName()).isEqualTo("Spain");
assertThat(c.getCities().stream().map(City::getName)).contains("Barcelona");
});
}
注意：该示例可以在 CountryRepositoryOtherTests 中找到。
防止误报成功测试
当使用任何带有参数的断言方法时，参数也必须包含在使用者中。否则，测试将一直通过 - 即使比较失败，这意味着错误的测试。仅当断言引发 or 异常时，测试才会失败。我想这很清楚，但很容易忘记它并写错测试。它不时发生在我身上。ThrowingConsumer assertThat RuntimeException AssertionError
不良做法
假设我们有几个国家/地区代码，我们想要验证每个代码是否满足某些条件。在我们的虚拟案例中，我们想断言每个国家/地区代码都包含“a”字符。正如你所看到的，这是无稽之谈：我们有大写的代码，但我们没有在断言中应用不区分大小写。
@Test
void assertValues() throws Exception {
var countryCodes = List.of("CZ", "AT", "CA");
assertThat( countryCodes )
.hasSize(3)
.allSatisfy(countryCode -> countryCode.contains("a"));
}
令人惊讶的是，我们的测试成功通过了。
良好做法
如本节开头所述，我们的测试可以通过消费者中的附加功能轻松纠正（第 7 行）。正确的测试应该是这样的：assertThat
@Test
void assertValues() throws Exception {
var countryCodes = List.of("CZ", "AT", "CA");
assertThat( countryCodes )
.hasSize(3)
.allSatisfy(countryCode -> assertThat( countryCode ).containsIgnoringCase("a"));
}
现在，测试按预期失败，并显示正确的错误消息。
java.lang.AssertionError:
Expecting all elements of:
["CZ", "AT", "CA"]
to satisfy given requirements, but these elements did not:
"CZ"
error:
Expecting actual:
"CZ"
to contain:
"a"
(ignoring case)
at com.github.aha.sat.core.clr.AppleTest.assertValues(AppleTest.java:45)
链断言
最后一个提示不是真正的实践，而是建议。应使用 AssertJ fluent API 来创建更具可读性的测试。
非链接断言
让我们考虑一下 test，其目的是测试组件的日志记录。这里的目标是检查：listLogs
断言收集的日志数
断言存在和日志消息DEBU GINFO
@Test
void listLogs() throws Exception {
ListAppender<ILoggingEvent> logAppender = ...;
assertThat( logAppender.list ).hasSize(2);
assertThat( logAppender.list ).anySatisfy(logEntry -> {
assertThat( logEntry.getLevel() ).isEqualTo(DEBUG);
assertThat( logEntry.getFormattedMessage() ).startsWith("Initializing Apple");
});
assertThat( logAppender.list ).anySatisfy(logEntry -> {
assertThat( logEntry.getLevel() ).isEqualTo(INFO);
assertThat( logEntry.getFormattedMessage() ).isEqualTo("Here's Apple runner" );
});
}
链接断言
通过上面提到的 Fluent API 和链接，我们可以这样更改测试：
@Test
void listLogs() throws Exception {
ListAppender<ILoggingEvent> logAppender = ...;
assertThat( logAppender.list )
.hasSize(2)
.anySatisfy(logEntry -> {
assertThat( logEntry.getLevel() ).isEqualTo(DEBUG);
assertThat( logEntry.getFormattedMessage() ).startsWith("Initializing Apple");
})
.anySatisfy(logEntry -> {
assertThat( logEntry.getLevel() ).isEqualTo(INFO);
assertThat( logEntry.getFormattedMessage() ).isEqualTo("Here's Apple runner" );
});
}
注意：该示例可在 AppleTest 中找到。文章来源：https://www.toymoban.com/news/detail-849361.html
摘要和源代码
AssertJ 框架为其流畅的 API 提供了很多帮助。在本文中，提供了一些技巧和提示，以产生更清晰、更可靠的测试。请注意，这些建议大多是主观的。这取决于个人喜好和代码风格。文章来源地址https://www.toymoban.com/news/detail-849361.html
到了这里，关于使用 AssertJ 进行单元测试的提示的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
