提交 3cb60a0b 编写于 作者: W wizardforcel

2021-10-05 23:30:35

上级 7f30ea13
......@@ -252,7 +252,7 @@ ISO/IEC-25000 的质量模型将产品质量模型(即内部和外部属性)
* **代码覆盖率**定义了源代码的程度,例如,已测试的 LOC 百分比。代码覆盖率有几个标准:
1. 语句覆盖率:代码覆盖粒度的一行。
2. 决策(分支)覆盖:控制结构(例如,if-else)覆盖粒度。
2. 决策(分支)覆盖:控制结构(例如,`if-else`)覆盖粒度。
3. 条件覆盖率:布尔表达式(真-假)覆盖粒度。
4. 路径覆盖:每个可能的路由覆盖粒度。
5. 函数覆盖:程序函数覆盖粒度。
......@@ -394,7 +394,7 @@ JUnit3 允许通过称为 TestRunner 的 Java 应用程序运行测试用例。J
构建工具(如 Ant 或 Maven)和**集成开发环境****IDE**)(如 Eclipse 和 IntelliJ)实现自己的 JUnit 测试运行程序是一种常见做法。
下图显示了当我们使用 JUnit Swing runner 时,以及当我们使用 Eclipse 运行相同的测试用例时,前面的测试是什么样子的。
下图显示了当我们使用 JUnit Swing 运行器时,以及当我们使用 Eclipse 运行相同的测试用例时,前面的测试是什么样子的。
![](img/00012.jpeg)
......@@ -443,7 +443,7 @@ JUnit4 仍然是一个开源框架,尽管许可证相对于 JUnit3 有所改
JUnit4 与 JUnit3 的主要区别之一是 JUnit4 允许定义测试的方式。在 JUnit4 中,Java 注释用于将方法标记为测试。因此,JUnit4 只能用于 Java5 或更高版本。正如 JUnit 4.0 的文档在 2006 年所述:
JUnit4.0 的体系结构与早期版本的体系结构有很大的不同。不再通过子类化 junit.framework.TestCase 来标记测试类,也不再通过以“test”开头的名称来标记测试方法,而是使用@test 注释来标记测试方法。
JUnit4.0 的体系结构与早期版本的体系结构有很大的不同。不再通过子类化`junit.framework.TestCase`来标记测试类,也不再通过以`test`开头的名称来标记测试方法,而是使用`@test`注释来标记测试方法。
# JUnit4 中的标准测试
......@@ -548,11 +548,11 @@ public class TestSimple {
# JUnit4 中的测试执行
测试运行程序的概念也出现在 JUnit4 中,但是相对于 JUnit3 它有了一些改进。在 JUnit4 中,测试运行程序是一个 Java 类,用于管理测试的生命周期:实例化、调用 setup 和 teardown 方法、运行测试、处理异常、发送通知等等。默认的 JUnit4 测试运行程序名为`BlockJUnit4ClassRunner`,它实现 JUnit4 标准测试用例类模型。
测试运行程序的概念也出现在 JUnit4 中,但是相对于 JUnit3 它有了一些改进。在 JUnit4 中,测试运行程序是一个 Java 类,用于管理测试的生命周期:实例化、调用配置和收尾方法、运行测试、处理异常、发送通知等等。默认的 JUnit4 测试运行程序名为`BlockJUnit4ClassRunner`,它实现 JUnit4 标准测试用例类模型。
在 JUnit4 测试用例中使用的测试运行程序可以简单地使用注释`@RunWith`进行更改。JUnit4 提供了一个内置测试运行程序的集合,允许更改测试类的性质。在本节中,我们将回顾最重要的部分。
* 为了运行一组测试(即测试套件),JUnit4 提供了`Suite`运行程序。除了 runner 之外,`Suite.SuiteClasses`类还允许定义属于该套件的各个测试类。例如:
* 为了运行一组测试(即测试套件),JUnit4 提供了`Suite`运行程序。除了运行器之外,`Suite.SuiteClasses`类还允许定义属于该套件的各个测试类。例如:
```java
package io.github.bonigarcia;
......
......@@ -43,9 +43,9 @@ JUnit 作为平台的成功阻止了 JUnit 作为测试工具的开发。我们
# JUnit 4 级运动员
JUnit4 的 runner API 也具有重要的威慑作用。如第 1 章“软件质量和 Java 测试回顾”所述,在 JUnit4 中,runner 是一个 Java 类,用于管理测试的生命周期。JUnit4 中的 runner API 非常强大,但是它有一个重要的缺点:runner 是不可组合的,也就是说,我们一次只能使用一个 runner
JUnit4 的运行器 API 也具有重要的威慑作用。如第 1 章“软件质量和 Java 测试回顾”所述,在 JUnit4 中,运行器是一个 Java 类,用于管理测试的生命周期。JUnit4 中的运行器 API 非常强大,但是它有一个重要的缺点:运行器是不可组合的,也就是说,我们一次只能使用一个运行器
例如,参数化测试不能与 Spring 测试支持相结合,因为两个测试都将使用自己的 runner 实现。用 Java 思考(参见下面给出的代码片段),每个测试用例都使用自己独特的`@RunWith`注释。第一个使用`Parameterized`跑步者:
例如,参数化测试不能与 Spring 测试支持相结合,因为两个测试都将使用自己的运行器 实现。用 Java 思考(参见下面给出的代码片段),每个测试用例都使用自己独特的`@RunWith`注释。第一个使用`Parameterized`跑步者:
```java
import org.junit.Test;
......@@ -63,7 +63,7 @@ public class MyParameterizedTest {
}
```
虽然第二个示例使用的是`SpringJUnit4ClassRunner`runner,但由于 JUnit4 的限制(runner 是不可组合的),它不会与前一个示例结合使用:
虽然第二个示例使用的是`SpringJUnit4ClassRunner`运行器,但由于 JUnit4 的限制(运行器是不可组合的),它不会与前一个示例结合使用:
```java
import org.junit.Test;
......@@ -568,7 +568,7 @@ Eclipse 中 ConsoleLancher 的示例
JUnit5 被设计为向前和向后兼容。一方面,Vintage 组件支持在 JUnit3 和 JUnit4 上运行遗留代码。另一方面,JUnit 5 提供了一个 JUnit 4 运行程序,它允许在 IDE 中运行 JUnit 5,并构建支持 JUnit 4 的系统,但还不能直接支持新的 JUnit 平台 5。
让我们看一个例子。假设我们想要在一个不支持 JUnit5 的 IDE 中运行 Jupiter 测试,例如旧版本的 Eclipse。在这种情况下,我们需要用`@RunWith(JUnitPlatform.class)`注释我们的 Jupiter 测试。`JUnitPlatform`runner 是一个基于 JUnit 4 的 runner,它支持在 JUnit 4 环境中运行其编程模型在 JUnit 平台上受支持的任何测试。因此,我们的测试结果如下:
让我们看一个例子。假设我们想要在一个不支持 JUnit5 的 IDE 中运行 Jupiter 测试,例如旧版本的 Eclipse。在这种情况下,我们需要用`@RunWith(JUnitPlatform.class)`注释我们的 Jupiter 测试。`JUnitPlatform`运行器是一个基于 JUnit 4 的运行器,它支持在 JUnit 4 环境中运行其编程模型在 JUnit 平台上受支持的任何测试。因此,我们的测试结果如下:
```java
package io.github.bonigarcia;
......
......@@ -301,13 +301,13 @@ class StandardAssertionsTest {
}
```
本节的以下部分回顾了 Jupiter 提供的 advance 断言:`assertAll``assertThrows``assertTimeout``assertTimeoutPreemptively`
本节的以下部分回顾了 Jupiter 提供的高级断言:`assertAll``assertThrows``assertTimeout``assertTimeoutPreemptively`
# 断言组
一个重要的木星断言是`assertAll`。此方法允许同时对不同的断言进行分组。在分组断言中,始终执行所有断言,任何失败都将一起报告。
方法`assertAll`接受 Lambda 表达式的 vargargs`Executable…`)或这些表达式的流(`Stream<Executable>`)。可选地,`assertAll`的第一个参数可以是用于标记断言组的字符串消息。
方法`assertAll`接受 Lambda 表达式的可变参数`Executable…`)或这些表达式的流(`Stream<Executable>`)。可选地,`assertAll`的第一个参数可以是用于标记断言组的字符串消息。
让我们看一个例子。在下面的测试中,我们使用 Lambda 表达式将几个`assertEquals`分组:
......@@ -450,7 +450,7 @@ class TimeoutWithResultOrMethodTest {
![](img/00049.gif)
assertTimeout第二例控制台输出
`assertTimeout`第二例控制台输出
另一个 Jupiter 超时断言称为`assertTimeoutPreemptively`。与`assertTimeoutPreemptively`关于`assertTimeout`的区别在于`assertTimeoutPreemptively`没有等到操作结束,当超过预期超时时,执行被中止。
......@@ -486,11 +486,11 @@ class TimeoutWithPreemptiveTerminationTest {
正如我们所看到的,为 Jupiter 提供的开箱即用的内置断言对于许多测试场景来说已经足够了。然而,有时可能需要更多的附加功能,例如匹配器。在这种情况下,JUnit 团队建议使用以下第三方断言库:
* [Hamcrest](http://hamcrest.org/):一个断言框架,用于编写 matcher 对象,允许以声明方式定义规则。
* [Hamcrest](http://hamcrest.org/):一个断言框架,用于编写匹配器对象,允许以声明方式定义规则。
* [AssertJ](http://joel-costigliola.github.io/assertj/):流畅的 Java 断言。
* [Truth](https://google.github.io/truth/):一个断言 Java 库,旨在使测试断言和失败消息更具可读性。
在本节中,我们将简要回顾 Hamcrest。这个库提供了断言`assertThat`,它允许创建可读的高度可配置的断言。方法`assertThat`接受两个参数:第一个是实际对象,第二个是`Matcher`对象。此匹配器实现接口`org.hamcrest.Matcher`,并启用预期的部分或精确匹配。Hamcrest 提供不同的 matcher 实用程序,例如`is``either``or``not``hasItem`。Matcher 方法使用生成器模式,允许组合一个或多个 Matcher 来构建 Matcher 链。
在本节中,我们将简要回顾 Hamcrest。这个库提供了断言`assertThat`,它允许创建可读的高度可配置的断言。方法`assertThat`接受两个参数:第一个是实际对象,第二个是`Matcher`对象。此匹配器实现接口`org.hamcrest.Matcher`,并启用预期的部分或精确匹配。Hamcrest 提供不同的匹配器实用程序,例如`is``either``or``not``hasItem``Matcher`方法使用生成器模式,允许组合一个或多个`Matcher`来构建`Matcher`链。
为了使用 Hamcrest,首先我们需要在项目中导入依赖项。在 Maven 项目中,这意味着我们必须在`pom.xml`文件中包含以下依赖项:
......@@ -1111,7 +1111,7 @@ class NestTest {
}
```
如果执行这个示例,只需查看控制台跟踪,就可以跟踪嵌套测试的执行。请注意,每次测试前都会执行 top`@BeforeEach`方法(称为`setup1`)。因此,在实际测试执行之前,跟踪`Setup 1`始终存在于控制台中。每个测试还向控制台写入一行代码。我们可以看到,第一个测试记录了`Test 1`。然后,执行内部类中定义的测试。第一个内部类执行测试`innerTest1`,但之后,执行顶级类和第一个内部类的设置方法(分别记录`Setup 1``Setup 2`
如果执行这个示例,只需查看控制台跟踪,就可以跟踪嵌套测试的执行。请注意,每次测试前都会执行顶部的`@BeforeEach`方法(称为`setup1`)。因此,在实际测试执行之前,跟踪`Setup 1`始终存在于控制台中。每个测试还向控制台写入一行代码。我们可以看到,第一个测试记录了`Test 1`。然后,执行内部类中定义的测试。第一个内部类执行测试`innerTest1`,但之后,执行顶级类和第一个内部类的设置方法(分别记录`Setup 1``Setup 2`
最后,执行最后一个内部类(`innerTest2`中定义的测试,但通常在测试之前执行设置方法的级联:
......@@ -1440,4 +1440,4 @@ Jupiter 提供了一组丰富的断言,这些断言是类`Assertions`中的静
我们已经了解了如何使用`@Nested`简单地注释内部 Java 类来创建嵌套测试。这可用于按照给定嵌套类关系的顺序创建测试执行。我们还研究了使用 JUnit5 编程模型创建重复测试的容易程度。注释`@RepeatedTest`用于该目的,提供重复测试指定次数的能力。最后,我们已经了解了 Jupiter 如何为几个遗留的 JUnit4 测试规则提供支持,包括`ExternalResource``Verifier``ExpectedException`
在第 4 章中“使用高级 JUnit 特性简化测试”我们继续发现 JUnit 编程模型。具体地说,我们回顾了 JUnit5 的高级特性,即依赖注入、动态测试、测试接口、测试模板、参数化测试、JUnit5 和 Java9 的兼容性。最后,我们回顾了 JUnit5.1 积压工作中计划的一些特性,在撰写本文时这些特性尚未实现。**
\ No newline at end of file
在第 4 章中“使用高级 JUnit 特性简化测试”我们继续发现 JUnit 编程模型。具体地说,我们回顾了 JUnit5 的高级特性,即依赖注入、动态测试、测试接口、测试模板、参数化测试、JUnit5 和 Java9 的兼容性。最后,我们回顾了 JUnit5.1 积压工作中计划的一些特性,在撰写本文时这些特性尚未实现。
\ No newline at end of file
......@@ -171,7 +171,7 @@ public class MockitoExtension
MockitoAnnotations.initMocks(testInstance)
```
这与在 Mockito 中使用 JUnit4 runner 的效果相同:`@RunWith(MockitoJUnitRunner.class)`
这与在 Mockito 中使用 JUnit4 运行器的效果相同:`@RunWith(MockitoJUnitRunner.class)`
此外,该扩展还实现了接口`ParameterResolver`。这意味着在注册扩展(`@ExtendWith(MockitoExtension.class)`的测试中允许方法级的依赖项注入。特别是,注释将为带有`@Mock`注释的测试参数(位于包`org.mockito`中)注入模拟对象。
......
......@@ -659,7 +659,7 @@ dependencies {
Mockito跑过JUnit赛跑者。它为我们创建所有必需的模拟,并通过测试将它们注入类中。有两种基本方法;我们自己实例化 mock,并通过类构造函数或使用一组注释将它们作为类依赖项注入。在下一个示例中,我们将看到如何使用注释来完成。
为了让类使用 Mockito 注释,它需要与`MockitoJUnitRunner`一起运行。使用 runner 简化了流程,因为您只需向要创建的对象添加注释:
为了让类使用 Mockito 注释,它需要与`MockitoJUnitRunner`一起运行。使用运行器简化了流程,因为您只需向要创建的对象添加注释:
```java
@RunWith(MockitoJUnitRunner.class)
......@@ -734,7 +734,7 @@ public class FriendshipsTest {
}
```
从本质上讲,runner 的操作与 Mockito runner 相同:
从本质上讲,运行器的操作与 Mockito 运行器相同:
```java
@TestSubject
......
......@@ -225,7 +225,7 @@ Then book is removed
# 杰伯哈夫
JBehave 需要两个主要组件来运行 BDD 故事和步骤。runner 是一个类,它将解析故事、运行所有场景并生成报告。步骤是与场景中编写的步骤相匹配的代码方法。该项目已经包含所有 Gradle 依赖项,因此我们可以直接创建 JBehave runner
JBehave 需要两个主要组件来运行 BDD 故事和步骤。运行器是一个类,它将解析故事、运行所有场景并生成报告。步骤是与场景中编写的步骤相匹配的代码方法。该项目已经包含所有 Gradle 依赖项,因此我们可以直接创建 JBehave 运行器
# JBehave 转轮
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册