如何写好单元测试

很多没习惯写单元测试的开发者,总觉得单元测试很难,还增加了工作了,或者把单元测试环境搭好了,也写了很多单元测试,越写越累,感觉代码质量没提高,工作量反而提高很多。我们一起来学习下为什么要写单元测试,以及如何写好单元测试。
我们分以下7个小点来讲解:
1.为什么要些单元测试?
2. 单元测试与集成测试的区别?
3. 先些代码还是先写单元测试?
4. 谁来编写单元测试 ?
5. 如何避免无用的测试 ?
6. 测试代码覆盖率?
7. 单元测试中的"mock仿件"或者我们说的打桩?
 

1、为什么要些单元测试?
目的:
1. 提高软件质量
2. 减少bug
3. 减少重复的工作
4. 安全的重构已有的代码
5. 让开发者对程序稳定性更有信心
重要性:
1. 运行单元测试是为了保证代码的行为和我们期望的结果一致。
2. 写单元测试会增加代码工作量,同时也节约了bug修复时间。
3. 如果没有写单元测试,没有发现bug的情况下,程序在测试人员测试的时候才发现问题或者在线上环境(正式环境)用户使用才发现问题,在去修复bug。开发会花大量的精力去修复bug和走部署流程,测试也会花大量的时间去做了重复的测试。很不划算。
4. 在线上某些场景下bug导致大量的数据丢失,需要花很大精力去修复数据,或者根本没办修复数据导致严重的后果。
 

2、单元测试与集成测试区别?
测试粒度不同: 单元测试是程序最小的单元,而集成测试是一个功能,一组功能或者整个系统上
单元测试:程序的最小单元。
集成测试:也叫组装测试或联合测试,是在单元测试的基础上,把所有模块按系统设计要求组装成功能或者系统,实际中程序单元,测试通过了,不能保证程序组装也能正常的工作,程序某些在局部反应不出问题,很有可能在全局或者特殊场景下暴露出问题。
单元测试和集成测试很容易混为一谈:因为单元测试和集成测试可以试用相同的工具和框架编写。
先写代码还是先写单元测试?
编码前,要先写测试,很多没有写过单元测试的朋友会想,代码都没有,连测试的对象都没有,我怎么写单元测试?
 1. 我们可以通过先话流程图,写伪代码或者建模来解决这个问题,这样让我们站在用户的角色去开发,尽早的发现问题
 2. 避免我们开发完了,某个功能模块遗漏了的情况。
 3. 这样开发出来的程序扩展性、维护性很容易理解。
 

4、谁来编写单元测试?
单元测试一般由开发员自己些,但是我们自己对自己的代码编写单元测试的情况下,习惯性的往理想情况下编写,开发员最好不要针对自己的代码编写单元测试。应该有其他开发编写,这样减少了bug也提高了开发的水平。
如何避免无用的测试?
1. 只写必要的测试
 编写自己觉得不靠谱的代码,例如业务很复杂自己没有吃透,以前没有写过,感觉会产生无法预料的结果。

2. 只写关键的测试
有时候必要的测试我们些不出来,也没有人知道,我们只能勉强跳过。但是关键性的测试不能跳过,关键性测试就是:你写的代码的核心洛基。如果你不知道怎么处理,你知道要保证最终要的那条路线是可以走通的,将来重构的时候,这条路线能确保你不会茫然。
3. 无用的测试
3.1 不要去测试开发语言的标准库和核心库,因为这些代码都是久经考验过得。虽然这些会出现小概率的错误。(如果你确定是开发语言的标准库或者核心库的问题,你应该测试标准库和核心库,因为它们都带有完整的测试用例)
3.2 不要去测试基础框架和工具方法和外部依赖的有效性,当你遇到这种问题,你应该打桩"mock"。
3.3 你只见过它测试通过,没有见过它测试失败,可能这种测试从头到尾都没测试任何代码,我们应该手动破坏代码,以确保帧的覆盖到了目标代码。
 

5、测试代码覆盖率?
我们应该忽略代码覆盖率:就算覆盖率达到100%,和"靠谱"的代码肯能有天壤之别,问题就在于有些公司把代码覆盖率作为考核的标准,这就让开发很容易就演变成"追求100%代码覆盖率",然后无所不用,连开发都不懂,那就更悲剧了,一群人对着水分极大的代码,然后对着"100%代码覆盖率"乐得合不弄嘴,想想都难受想哭。
测试中的仿件"mock"或者我们说的打桩?
有时候对被测试的系统进行测试很困难,因为它依赖无法在测试环境中使用的对象、组件、API或者它们不可用。在这种情况下,我们确保测试系统的内部行为有更多的控制性和可见性,我们可以使用仿件"mock"或者打桩。
什么情况下使用"仿件mock、桩件stubs" ?
1. 外部依赖不存在。
2. 外部依赖不会返回测试需要的结果,或者它有不良的副作用。
3. 如果外部依赖更变,会导致我们的测试失败。
 我们来看一个打桩示例:
1. 我们在编写单元测试购物车"Cart"类,依赖产品类"Product"和用户类"User"。
2. 依赖产品类"Product"和用户类"User"已经测试过了。
3. 依赖的产品类"Product"和用户类"User"是由他人开发的。
示例问题:
1. 产品类"Product"和用户类"User"一旦出现问题,不会让我们误以为购物车类"Cart"出了问题。
2. 不用为了创造很多前置条件,才能做出断言。(如果这样你应该把它放到集成测试)。
3. 在测试购物车时,我们应该避免使用"new Cart($userId, $productId, $quantity)"这种方式,这样会出现程序中很多地方都去做了重复的查询,并且影响程序的执行效率,更不利于打桩,我们应该使用这种方式"new Cart(User $user, Product $product, $quantity)"

作者:长风Drupal开发 赵威杰

联系我们

提供基于Drupal的门户网站、电子商务网站、移动应用开发及托管服务

联系电话
137-9572-6015
长按加微信
长风云微信
长按关注公众号
长风云公众号