测试篇——初探单元测试

初探单元测试

目录:

  • 单元测试的核心意义

  • 单元测试的特点

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

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

时间: 2024-10-09 18:23:47

测试篇——初探单元测试的相关文章

.net测试篇之单元测试/集成测试神器Autofixture

系列目录 autofixture简介 有了单元测试框架加上Moq(后面我们会用单独章节来介绍moq),可以说测试问题基上都能搞定了.然而有了AutoFixture对单元测试来说可以说是如虎添翼,AutoFixture并且它能与moq,rhinomock等框架结合,对单元测试带来的便捷性,可维护性和扩展性更是难以言表,只有用用了才知道. 说了这么多,还没有介绍AutoFixture是干什么的,其实AutoFixture就是一个假数据填充工具. 其实不论是Nunit还是Xunit都有数据填充功能,并

Core篇——初探IdentityServer4(客户端模式,密码模式)

Core篇--初探IdentityServer4(客户端模式,密码模式) 目录 1.Oatuth2协议的客户端模式介绍2.IdentityServer4客户端模式实现3.Oatuth2协议的密码模式介绍4.IdentityServer4密码模式实现 Oatuth2协议的客户端模式介绍 Client Credentials Grant (客户端模式)是Oauth2.0协议中,四种模式自建单的一种.它由两部分构成,客户端和认证服务器.认证服务器确认客户端无误后返回一个token,客户端请求带着tok

解码器开发小记-实车测试篇

解码器产品研发 实车测试是解码器产品开发的重点环节, 从某种程度上来看实车验证的工作基本上能看出整一个解码器公司的研发水平. 1. 整个解码器公司在对市场资源和研发进度调配的一个可见验收指标. 车源数量.测试条件能否达标,是出差能否达成既定计划的两个基本要素. 通俗的讲, 能否找到未来市场和现有市场需求的车源从而使自身产品在推出之时就能达到市场价值预期, 是评测车辆资源是否合格的唯一标准. 2. 研发管理实力的直接体现. 不同体系的解码器公司对于实车测试的工作步骤大径相庭, 不论哪种开发模式,

Windows Phone 8 测试自动化初探 (利用Coded UI)

前言 Windows Phone是个相对新的的平台,目前应用的数量少,相同应用的功能实现度也不如iOS和Android. 那么在Windows Phone上面的自动化测试的解决方案有什么? 目前就msdn来看,SeeTest是微软推荐的测试方案. 大家知道微软在VS里面集成了自动化测试工具Coded UI,那么Coded UI除了能测Windows, Web应用,它能不能支持Windows Phone应用呢? 利用Coded UI做Win Phone自动化的过程 利用Coded UI是可以做Wi

[老老实实学WCF] 第四篇 初探通信--ChannelFactory

原文:[老老实实学WCF] 第四篇 初探通信--ChannelFactory 老老实实学WCF 第四篇 初探通信--ChannelFactory 通过前几篇的学习,我们简单了解了WCF的服务端-客户端模型,可以建立一个简单的WCF通信程序,并且可以把我们的服务寄宿在IIS中了.我们不禁感叹WCF模型的简单,寥寥数行代码和配置,就可以把通信建立起来.然而,仔细品味一下,这里面仍有许多疑点:服务器是如何建起服务的?我们在客户端调用一个操作后发生了什么?元数据到底是什么东西?等等.我们现在对WCF的理

(转)[老老实实学WCF] 第四篇 初探通信--ChannelFactory

第四篇 初探通信--ChannelFactory 通过前几篇的学习,我们简单了解了WCF的服务端-客户端模型,可以建立一个简单的WCF通信程序,并且可以把我们的服务寄宿在IIS中了.我们不禁感叹WCF模型的简单,寥寥数行代码和配置,就可以把通信建立起来.然而,仔细品味一下,这里面仍有许多疑点:服务器是如何建起服务的?我们在客户端调用一个操作后发生了什么?元数据到底是什么东西?等等.我们现在对WCF的理解应该还处于初级阶段,我们就会觉得有许多这样的谜团了. 虽然我们生活在WCF为我们构建的美好的应

【测试篇】工作指南

[测试篇] 1. Bug统一使用禅道管理系统进行管理: 2. 测试环境的搭建与更新统一由测试组进行管理(遇到困难时需及时向开发工程师寻求帮助): 3. 测试人员需尽早的,并积极参与到每一次需求讨论.评审活动中去: 4. 需求评审通过后,测试人员需尽快针对本次迭代的需求,设计测试用例:测试用例直接写在禅道当中,与需求关联起来. 5. 测试用例设计完成后,需进行用例评审:先内部进行评审.完善,然后邀请开发人员.产品经理一起进行评审:但评审时间不宜过长(建议不超过40分钟),抓大放小:保证测试人员.开

python unittest 测试所有相关单元测试

python unittest 测试所有相关单元测试 python -m unittest discover project_directory "ut_*.py" 原文地址:https://www.cnblogs.com/bingwork/p/9714318.html

《Java从入门到放弃》JavaSE入门篇:单元测试

单元测试其实没什么好说的,直接看操作步骤! 我们来测试前一篇的小明买食物的方法. 第一步:在小明类上点右键,然后再new一个JUnit Test Case 第二步:继续点下一步,图上的内容相信大家都看得懂吧,如果看不懂···,那就要么学习,要么放弃吧,哈哈! 第三步:勾选要测试的方法: 第四步:点击OK,导入使用JUnit需要使用的Jar包 第五步:自动生成了一个xxxTest的类,里面包含一个testxxx的方法,上面有一个@test注解,因为我们没有勾选初始化的方法,所以所有的代码都直接写在