认识达内从这里开始

单元测试是大多数软件测试程序员都需要熟练掌握的一种测试方式，而本文我们就通过案例分析来简单了解一下，单元测试入门需要掌握哪些知识点。

一、测试替身

测试替身的作用是隔离被测代码，加速执行测试，使执行变得确定，模拟特殊情况，暴露隐藏信息。

其中隔离被测代码，使测试有针对性和容易理解，而利用测试替身实现的隔离，还有个副作用，那就是测试替身的速度要比本尊快很多。

测试替身的类型：

Stub(测试桩)：一个对象的所有方法只有一行，且各自返回一个适当的默认值。使用场景：只关心协作对象输送的响应。

Fake(伪造对象)：可以返回硬编码值，而每个测试可能需要有差异地实例化来返回不同值，模拟不同场景。使用场景：所依赖的服务或组件无法供测试使用，打桩产生了难以维护的糟糕代码。

Spy(测试间谍)：用于记录过去发生的情况，这样测试在事后就知道所发生的一切。使用场景：将其作为参数传递被测函数中。

Mock(模拟对象)：是特殊的Spy，在一个特定情景下可配置行为的对象。使用场景：关心某些交互，即两个对象之间的方法调用。

二、设计指南

避免测试中包含逻辑，不应该有switch、if-else等判断语句，for、while等循环语句。以免测试难以阅读和理解，难以复现，难以命名。

只测试一个关注点，一个工作单元只有一个终结果，例如一个返回值、系统状态的一个改变或对三方对象的一个调用。

专注检查行为而非实现，避免过度指定，只需检查终行为的正确性即可，既不要使用多个模拟对象，也不要对一个被测对象的纯内部状态进行断言。

避免复杂的私有方法，不要直接测试private方法。

避免在构造函数中包含需要测试的代码逻辑。

避免单例，单例模式会妨碍创建不同的变体。

使用new时要当心，实例化的对象，应该仅限于不会替换为测试替身的对象。

三、测试坏味道

1)可读性

程序员用测试的方式来表达和验证代码的假设和预期行为。

阅读测试代码之后，就该理解代码应当做什么。程序员运行那些测试时，就该了解代码实际上在做什么。

问题：基本断言缺乏意义，因为断言的基本原理和意图隐藏在看上去无意义的单词和数字背后，造成难以理解。

改进：去掉魔法数字，改用断言方法，使用编程语言内置的API语法。

问题：过度断言很脆弱，并且掩盖了整体广度和深度之下的意图。

改进：识别无关细节并移除。

问题：人格分裂是指一个测试检查了多件事。

改进：去掉重复，将粗粒度的场景分离。

问题：过分保护是指在测试开头增加守卫语句和空值检查保护自己。

改进：去除冗余断言，检查要使真正的断言通过所需的中间条件。

2)可维护性

代码从不慢慢退化，而是直接奔溃。

测试也是如此，同样脆弱，程序员编写自动化的单元测试来尽可能地管理这种脆弱性。

大家都知道维护噩梦是什么，你绝对不希望你的测试代码沦落其中。

问题：重复明显的是某一个数字或字符串在代码中反复出现。

改进：将可变数据提炼到局部变量中。

问题：残缺的文件路径会使代码无法转移，只能在某个人的计算机中。

改进：避免绝对路径，选择相对路径，用流来替换文件。

问题：像素完美出现的场景包括期望和实际产生的图像完美匹配。

改进：用适当的抽象层次来表达测试，将背后的细节隐藏到自定义断言中，进行模糊匹配。

3)可信度

软件开发其实就是在修改、演进和维护代码，如果不能信任测试，那么在即使看似无辜的改动之后，仍然不能确信代码是否能够工作。

接下来会围绕测试不可靠的问题来检阅测试坏味道。

问题：永不失败的测试不具有价值，给你虚假的安全感。

改进：养成运行测试的习惯，例如临时修改被测代码来故意触发一次失败。

问题：轻率承诺是指测试实际上没有测试任何东西，或名不符实。

改进：确保断言了一些事情，确切找出要检查的行为，也更容易命名。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。