Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
apachecn-java-zh
提交
3cb60a0b
A
apachecn-java-zh
项目概览
OpenDocCN
/
apachecn-java-zh
大约 1 年 前同步成功
通知
5
Star
53
Fork
13
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
apachecn-java-zh
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
3cb60a0b
编写于
10月 05, 2021
作者:
W
wizardforcel
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
2021-10-05 23:30:35
上级
7f30ea13
变更
6
显示空白变更内容
内联
并排
Showing
6 changed file
with
20 addition
and
20 deletion
+20
-20
docs/master-soft-test-junit5/1.md
docs/master-soft-test-junit5/1.md
+5
-5
docs/master-soft-test-junit5/2.md
docs/master-soft-test-junit5/2.md
+4
-4
docs/master-soft-test-junit5/3.md
docs/master-soft-test-junit5/3.md
+7
-7
docs/master-soft-test-junit5/5.md
docs/master-soft-test-junit5/5.md
+1
-1
docs/test-driven-java-dev/02.md
docs/test-driven-java-dev/02.md
+2
-2
docs/test-driven-java-dev/08.md
docs/test-driven-java-dev/08.md
+1
-1
未找到文件。
docs/master-soft-test-junit5/1.md
浏览文件 @
3cb60a0b
...
...
@@ -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
;
...
...
docs/master-soft-test-junit5/2.md
浏览文件 @
3cb60a0b
...
...
@@ -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
;
...
...
docs/master-soft-test-junit5/3.md
浏览文件 @
3cb60a0b
...
...
@@ -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
docs/master-soft-test-junit5/5.md
浏览文件 @
3cb60a0b
...
...
@@ -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`
中)注入模拟对象。
...
...
docs/test-driven-java-dev/02.md
浏览文件 @
3cb60a0b
...
...
@@ -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
...
...
docs/test-driven-java-dev/08.md
浏览文件 @
3cb60a0b
...
...
@@ -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.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录