Loading

测试篇——初探单元测试

初探单元测试

目录:

  • 单元测试的核心意义

  • 单元测试的特点

  • 一个简单的单元测试demo

  • 构建可测试的代码以及初探Mock框架NSubstitute

 

单元测试的核心意义

  • 验证代码健壮性,无 Bug
  • 项目升级,重构后涉及到旧的逻辑,保证以旧逻辑的稳定运行

单元测试的特点

  • 单元测试可重复运行
  • 单元测试持续长期有效,并且返回结果一致
  • 单元测试在内存中运行,不会依赖外部组建(例如真实的数据库,真实的文件等)
  • 单元测试可以快速返回结果
  • 一个测试方法只测试一个问题(最小的粒度)

一个简单的单元测试demo

  • 这里创建一个类 Product 代表商品; ProductCollection 代表配送的商品集合, DistributeProduct 方法根据传入的商品 Id 集合代表需要配送的商品(具体看项
    目代码)

  • 创建一个基于 Framework 的单元测试项目 MyUnitTestApplication ,添加一个单元测试类 ProductCollectionTests , ,添加一个单元测试方
    法 ProductCollction_DistributeProduct_Test

    • 注意点 1 :单元测试方法命名规范一般是 测试主体 _ 期待返回结果 _ 传入参数。
    • 注意点 2 :单元测试类需要添加 [TestClass] 特性,单元测试方法需要 [TestMethod] 特性修饰
    • 在单元测试的方法体内右键运行单元测试,如下图所示,可以在右侧测试资源管理器中看到看到运行结果;例如把第三个断言修改成一个错误的结果,右
      键运行单元测试,就会出现测试未通过显示。

    • 这样一个最简单的单元测试就写完了,假如将来有人修改了 DistributeProduct 方法,再将这个单元测试运行一遍就可以验证修改是否存在 Bug.

构建可测试性的代码

  • 关于 demo 的依赖性问题:单元测试的用例能够成功运行取决于内部所有逻辑正常运行,例如上面 demo 中的测试核心是 DistributeNotice 对象,因为测试

的是它的 ToNotice 方法向外部发送通知消息。所以这里的 ProductCollection 对象依赖于 DistributeNotice 对象。但是,一般向外部发送信息需要 一些配置以

及 第三方的代理类(外部依赖)。例如如下图所示: DirstributeNotice 对象依赖着 ConfigurationManager 和 EmailSend 。此时单元测试已经不能进行了,因为需
要考虑其他的外在因素。

  •   

     

  • 我们的解决方案是:此时我们可以添加一个 间接层。让原本依赖于 类或者 外部资源的对象抽象成依赖于它们的 接口,然后通过接口动态生成一个模拟的实现
    类。(这也是设计原则中所谓的 面向接口编程)于是我们的依赖关系变为下图:

 

  • 修改我们的代码,将实现类抽象成为接口;

基于接口重写编写单元测试,这里我们用到了 Mock 接口单元测试,使用了开源的 Mock 框架 NSubstitute 。(测试过程中替代真实对象的内存级别虚
拟对象)

  • 所以,单元测试的关键是面向接口,面向抽象。使各个组件,各个类依赖于接口,当代码耦合度过高将无法进行单元测试。
  • 当我们需要测试一些类中受保护的方法测试时候,将会遇到下面的问题:
    •  在我们实现业务过程中,在类的内部经常会出现一些受保护的方法,然后测试类只会有一个公共的入口,此时我们要怎样测试这些受保护的方

      法的业务逻辑呢?例如下图所示:我们在我们的 ProductCollection 集合类中添加一个方法 ValidatorProduct , ,根据产品的编号,判断产品的数量和价格是否合适,从而

      判断这个产品是否合适。在编写方法过程中,我们遵循单一职责原则,将验证逻辑碎片化以备将来扩展和重用,但是这些逻辑都是重要逻辑,我们想
      要测试它们,然而我们只有一个公共的方法入口 ValidatorProduct ,我们不能单独的测试其中一个的逻辑。

此时我们的解决方案是:我们可以在测试环境下,提供一个继承于测试类的子类,在子类中提供这些方法的可测试版本。如下图所示:我们建立了一个子

类 ProductCollectionAccessibility , ,通过继承的方式,在 ValidatorPriceAccessibility 方法中和 ValidatorNumberAccessibility 分别测试父类的验证产品价格和数
量的方法。

我们经常需要完善我们的测试用例,

  • 我们的代码完成后会持续的进行修改,重构。在这个过程中,代码会进行修改,从而会对以前的代码造成影响。此时我们就需要一个保障。这个保证就是

单元测试,基于一个测试用例很完善的单元测试项目,我们修改后,只需要将单元测试重新运行一遍,就可以保证重构修改代码是否有 Bug ,是否有副作
用。

  • 单元测试不仅仅验证代码正确性,无 Bug, 也保证了代码在生命周期中一直被完善和重构,让其越来越有价值,不会成为公司的技术债务。
posted @ 2018-07-15 23:35  3WLineCode  阅读(137)  评论(0编辑  收藏  举报