标签：接口编程   依赖   单元   影响   dem   ima   怎样   面向   生命周期   

初探单元测试

目录：

• 单元测试的核心意义

• 单元测试的特点

• 一个简单的单元测试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, 也保证了代码在生命周期中一直被完善和重构，让其越来越有价值，不会成为公司的技术债务。

测试篇——初探单元测试

标签：接口编程   依赖   单元   影响   dem   ima   怎样   面向   生命周期   

原文地址：https://www.cnblogs.com/liumengchen-boke/p/9315625.html