极客视点
极客时间编辑部
极客时间编辑部
113244 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/06:02
登录|注册

单元测试的五个主要准则

讲述:丁婵大小:8.29M时长:06:02
你好,欢迎收听极客视点。
自动化测试是所有大型软件项目不可或缺的一部分。它是提高质量、生产力和灵活性的一种手段。 因此,对系统架构进行合理的设计以便利后续的开发和自动化测试变得至关重要。自动化测试类型可以分为单元测试、集成测试和 GUI 测试,从时间和资源使用而言,单元测试的开发及运行成本低,并且单元测试专注于测试与外部依赖项隔离的单个系统组件。最近,托马斯·维利娜(Thomas Vilhena)分享了提升单元测试架构性能的 5 个主要准则,InfoQ 对其进行了翻译,供你参考。

一、软件复杂度

通常情况下,系统的复杂性越高,维护和测试就越困难,这引出第一个准则:密切关注软件的复杂度并遵循设计原则来控制它。
在提高测试性能的同时管理复杂性的方面,值得一提的一个实践方法是,在系统设计中尽可能采用纯函数和不变性。 纯函数是具有以下属性的函数:
对于相同的参数,其返回值是相同的。
它的评估测试不会产生副作用。
可以看出,纯函数非常适合单元测试,它们的使用也消除了许多补充性实践的需求。
不变性起着同等重要的作用,不可变对象是创建后状态无法修改的对象,它们更易于交互和具有可预测性,从而有助于降低系统复杂性,消除全局状态。

二、依赖隔离

按照单元测试定义,单元测试旨在隔离测试各个系统组件,因为你肯定不希望组件的单元测试结果受到其依赖项的影响。隔离程度会根据被测组件的具体情况以及每个开发团队的偏好而有所不同,你可能不担心隔离轻量级的内部业务类,因为用功能几乎相同的测试组件替代它们不会显示有什么附加影响。这里的策略可能很简单:在组件设计中应用依赖反转模式。
依赖反转模式(DIP)指出,高级和低级对象都应依赖抽象(例如接口),而不是特定的具体实现。一旦将系统组件从其依赖关系中解耦出来,你就可以在单元测试的上下文中通过简化的、针对测试的具体实现轻松地替换它们。

三、Mocks vs Fakes

Mocks 指模拟对象,它以有限的受控方式模拟了真实对象的行为。使用完全兼容的“fake”实现,可以为你提供编写单元测试的更大灵活性,相比设置模拟对象,它以更加可靠的方式从多个单元测试类中进行重用。
为了更详细地说明,假设你正在为依赖 FileStore 抽象类的组件编写单元测试。在此测试中,该组件将一条记录添加到文件存储中,但并不担心操作是否成功,因此你决定以“虚拟”方式模拟该操作。
现在,假设稍后需求发生变化,并且组件需要确保在继续操作之前通过从文件存储中读取文件来创建文件,从而迫使你更新模拟的行为以通过测试。然后,想象需求又发生了变化,并且组件需要写入多个文件,这迫使你的模拟对象行为再次进行修改。你知道发生了什么吗?你正在慢慢改进你的模拟,使其代码更趋近于具体的实现。
更糟糕的是,你最终可能会在整个代码库中散布很多独立的,半成品的模拟实现,每个单元测试类对应一个,从而导致测试环境更多的维护工作以及较低的内聚性。为了解决这种情况,就提出了以下准则:依靠 Fakes 而不是 Mocks 来实施单元测试,将其视为一等的公民,并将其组织为可重用的模块。
由于 Fake 组件实现了业务行为,因此与设置模拟对象相比,它们本质上是更昂贵的初始投资。但是,它们的长期回报肯定更高,并且更符合有效的单元测试的特性。

四、编码风格

每个自动化测试都可以描述为三步:
第一,准备测试环境
第二,执行关键操作
第三,验证结果
(Given) 给定已知的初始状态,(When) 然后执行某项操作,(Then) 每次操作最终都应产生相同的预期结果,这是非常符合逻辑的思考过程。为了使结果变得不同,必须更改初始状态,或者更改操作实现本身。
利用 Given-When-Then 模式可以编写可读性高以及结构清晰的单元测试代码。这一概念很简单:为单元测试定义和实施单一标准化的编码风格。

五、测试上下文管理

单元测试上下文管理是一个讨论不够多的话题。“测试上下文”是指成功运行单元测试所需的整个依赖注入以及初始状态设置。
当开发人员花费更少的时间来设置测试上下文环境并腾出时间编写测试用例时,单元测试会更有效。大量的测试案例可以共享一些测试上下文:利用构造器类将测试上下文的构建与单元测试用例的实现分开。
这个想法是将测试上下文的构造逻辑封装在构造器类中,并在单元测试类中引用它们。然后,每个上下文构造器负责创建特定的测试方案,并可选择地定义用于使其特定化的方法。
以上就是今天的内容,希望对你有所帮助。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 明格尔
    测试上下文构造没用过,有安案例吗
收起评论
大纲
固定大纲
一、软件复杂度
二、依赖隔离
三、Mocks vs Fakes
四、编码风格
五、测试上下文管理
显示
设置
留言
1
收藏
66
沉浸
阅读
分享
手机端
快捷键
回顶部