日常工作中,不管你是写Unit Test,还是采用TDD的编程方式进行开发,都会遇到断言。而断言的风格常见的会有Assert、BDD风格,对于这些常见的断言风格你怎么选择呢?
JUnit中提供了这样的assert断言风格,例如:
[@Test](https://my.oschina.net/azibug)
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() {
EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED);
String result = entranceMachine.execute(Action.INSERT_COIN);
assertEquals("opened", result);
assertEquals(EntranceMachineState, entranceMachineState.UNLOCKED);
}
Hamcrest和AssertJ都提供了assertThat()这样风格的断言,例如:
AssertJ提供的assertThat()的断言语法
[@Test](https://my.oschina.net/azibug)
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() {
EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED);
String result = entranceMachine.execute(Action.INSERT_COIN);
assertThat(result).isEqualsTo("opened");
assertThat(EntranceMachineState).isEqualsTo(entranceMachineState.UNLOCKED);
}
Hamcrest提供的assertThat()断言语法
[@Test](https://my.oschina.net/azibug)
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() {
EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED);
String result = entranceMachine.execute(Action.INSERT_COIN);
assertThat(result, is("opened"));
assertThat(EntranceMachineState, is(entranceMachineState.UNLOCKED));
}
对比上面三种断言语法,因为场景简单,所以结果差异并不是很大。对于我个人更加偏向于使用AssertJ提供的断言风格。因为这种风格避免JUnit提供的断言中经常遇到的问题,expected在前还是actural在前的问题。相比于Hamcrest的断言风格,在日常工作中综合对比发现AssertJ的更加清晰,毕竟AssertJ中assertThat只需要接收一个参数,而不用关注括号是否对齐的问题。
日常工作中如果使用TDD,且场景适当(例如上面例子),那么Hamcreate和AssertJ的差别不是很大。JUnit5默认提供了Hamcreate的断言,不需要额外的再引入其他依赖。
代码的可读性越来越收到开发者的重视。测试代码的可读性同样重要,为了让测试代码结构清晰,便于业务逻辑变动时能快读读懂测试的上下文,很多开发团队约定了BDD的风格来组织测试代码。其中包含两部分的约定:测试方法名的约定,测试代码段落的约定。
例如前面的例子:
[@Test](https://my.oschina.net/azibug)
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() {
...
}
虽然方法名很长,但是通过方法名我们能够快速知道测试类中有哪些测试,通过方法名我们能够清晰的当前测试的上下文,在测什么,期望的结果什么。通过方法名而不是通过比方法名长很多的代码段来获取测试在测什么的信息,毕竟阅读代码时间和修改代码时间可能是10:1,甚至20:1。所以团队约定BDD的风格组织在后续修改代码时,是受益良多的。
当需要也带具体的测试代码的时候,团队发现按照BDD这种三段式的风格来组织代码受益良多。例如:
[@Test](https://my.oschina.net/azibug)
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() {
EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED);
String result = entranceMachine.execute(Action.INSERT_COIN);
assertThat(result).isEqualsTo("opened");
assertThat(EntranceMachineState).isEqualsTo(entranceMachineState.UNLOCKED);
}
我们可以清晰的知道哪行代码在描述上下文,哪几行代码在描述测试意图,哪几行代码在描述测试结果验证。
BDD的风格能够帮助团队将测试代码维护的较为清晰。AssertJ提供了BDD风格的断言方式。使用then()语法。例如:
@Test
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() {
EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED);
String result = entranceMachine.execute(Action.INSERT_COIN);
then(result).isEqualsTo("opened");
then(EntranceMachineState).isEqualsTo(entranceMachineState.UNLOCKED);
}
断言变化不大。但是真正仔细读的时候,会发现使用then()还是简单那么一点点的。
我们常用的Mock工具Mockito,也提供了BDD风格的断言:then(), should(), and()。
import static org.mockito.BDDMockito.then;
import static org.assertj.core.api.BDDAssertions.and;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.times;
@SuppressWarnings("static-access")
@Test
public void bdd_assertions_with_bdd_mockito() {
Person person = mock(Person.class)
person.ride(bike);
person.ride(bike);
then(person).should(times(2)).ride(bike);
and.then(person.hasBike()).isTrue();
}
所以日常开发中,我会首先选择then(),其次会选择assertThat()。
当我们需要为某个结果测试多个测试点时,如果为每个测试点都组织一次相同的上下文,那么重复代码太多。带来的价值就是那么一点点区别,所以在测试力度上我们可以根据经验来在开发工程中动态调整。
下面据一个例子,当我们需要验证有一个查询方法返回的List的结果时,不单单要验证List中元素的数量,还要验证元素是否时期望的顺序。那么流式写法会缩减一部分重复的断言代码。
then(users).hasSize(3)
.containsExactlyInAnyOrder(
firstUser,
secondUser,
thirdUser);
上面是日常工作中经常使用到的断言技巧,你的怎么选择的呢?那种风格无所谓能工作就行?
Original url: Access
Created at: 2019-12-26 09:49:40
Category: default
Tags: none
未标明原创文章均为采集,版权归作者所有,转载无需和我联系,请注明原出处,南摩阿彌陀佛,知识,不只知道,要得到
java windows火焰图_mob64ca12ec8020的技术博客_51CTO博客 - 在windows下不可行,不知道作者是怎样搞的 监听SpringBoot 服务启动成功事件并打印信息_监听springboot启动完毕-CSDN博客 SpringBoot中就绪探针和存活探针_management.endpoint.health.probes.enabled-CSDN博客 u2u转换板 - 嘉立创EDA开源硬件平台 Spring Boot 项目的轻量级 HTTP 客户端 retrofit 框架,快来试试它!_Java精选-CSDN博客 手把手教你打造一套最牛的知识笔记管理系统! - 知乎 - 想法有重合-理论可参考 安宇雨 闲鱼 机械键盘 客制化 开贴记录 文本 linux 使用find命令查找包含某字符串的文件_beijihukk的博客-CSDN博客_find 查找字符串 ---- mac 也适用 安宇雨 打字音 记录集合 B站 bilibili 自行搭建 开坑 真正的客制化 安宇雨 黑苹果开坑 查找工具包maven pom 引用地 工具网站 Dantelis 介绍的玩轴入坑攻略 --- 关于轴的一些说法 --- 非官方 ---- 心得而已 --- 长期开坑更新 [本人问题][新开坑位]关于自动化测试的工具与平台应用 机械键盘 开团 网站记录 -- 能做一个收集的程序就好了 不过现在没时间 -- 信息大多是在群里发的 - 你要让垃圾佬 都去一个地方看难度也是很大的 精神支柱 [超级前台]sprinbboot maven superdesk-app 记录 [信息有用] [环境准备] [基本完成] [sebp/elk] 给已创建的Docker容器增加新的端口映射 - qq_30599553的博客 - CSDN博客 [正在研究] Elasticsearch, Logstash, Kibana (ELK) Docker image documentation elasticsearch centos 安装记录 及 启动手记 正式服务器 39 elasticsearch 问题合集 不断更新 6.1.1 | 6.5.1 两个版本 博客程序 - 测试 - bug记录 等等问题 laravel的启动过程解析 - lpfuture - 博客园 OAuth2 Server PHP 用 Laravel 搭建带 OAuth2 验证的 RESTful 服务 | Laravel China 社区 - 高品质的 Laravel 和 PHP 开发者社区 利用Laravel 搭建oauth2 API接口 附 Unauthenticated 解决办法 - 煮茶的博客 - SegmentFault 思否 使用 OAuth2-Server-php 搭建 OAuth2 Server - 午时的海 - 博客园 基于PHP构建OAuth 2.0 服务端 认证平台 - Endv - 博客园 Laravel 的 Artisan 命令行工具 Laravel 的文件系统和云存储功能集成 浅谈Chromium中的设计模式--终--Observer模式 浅谈Chromium中的设计模式--二--pre/post和Delegate模式 浅谈Chromium中的设计模式--一--Chromium中模块分层和进程模型 DeepMind 4 Hacking Yourself README.md update 20211011
Laravel China 简书 知乎 博客园 CSDN博客 开源中国 Go Further Ryan是菜鸟 | LNMP技术栈笔记 云栖社区-阿里云 Netflix技术博客 Techie Delight Linkedin技术博客 Dropbox技术博客 Facebook技术博客 淘宝中间件团队 美团技术博客 360技术博客 古巷博客 - 一个专注于分享的不正常博客 软件测试知识传播 - 测试窝 有赞技术团队 阮一峰 语雀 静觅丨崔庆才的个人博客 软件测试从业者综合能力提升 - isTester IBM Java 开发 使用开放 Java 生态系统开发现代应用程序 pengdai 一个强大的博主 HTML5资源教程 | 分享HTML5开发资源和开发教程 蘑菇博客 - 专注于技术分享的博客平台 个人博客-leapMie 流星007 CSDN博客 - 舍其小伙伴 稀土掘金 Go 技术论坛 | Golang / Go 语言中国知识社区
最新评论