单元测试培训系列:(一)单元测试概念以及必要性

简介:

说起单元测试,多数同学应该都知道或听过,可能不少同学认为自己也写过,甚至觉得单元测试很简单有什么好培训的?其实这个事情还真没想象的那么简单!我基本可以比较负责任的说,你若没深入对单元测试做过研究,不知道Mock对象为何物的话,那么可能你以前写过的单元测试压根就不是单元测试。

  单元测试是什么?

  这个问题其实并不太容易一两句话说得特别清楚。先借用下百度百科的定义:

  单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

  从以上这句定义我们可以看到,两个提取到到两个非常关键的字:最小粒度、隔离

  ● 单元测试是测试的最小单位,必须可信任的,可重复执行的。

  ● 如果测试的范围轻易的就会扩展到其他类或同类的其他方法,那就不再是最小单位,也就不是单元测试了!

  例如:

  类A中的方法CallMethod中调用了类B中的方法DoMethod,如果在编写测试的时候不把B类中的DoMethod隔离出来,造成单元测试CallMethod方法时,实际实行了DoMethod方法,那么这个测试方法不能算作是单元测试。(如何隔离会在后文详解)

  单元测试的目的是什么?

  有人曾给我一段非常简单的代码片段:一个方法,里面只是调用若干个其他方法,甚至也都没有任何返回值,然后问我这种代码写单元测试有任何价值?!完全是浪费体力!!

    public class ClassA
    {
        
public void CallMethod()
        {
            DoSomethingForYou();
            DoSomethingForThem();
            DoSomethingForMe();
        }
    }

  其实提出这个疑问主要有两个原因导致:未能理解单元测试的目的是什么以及这段代码的可测试性并不高。(可测试性以及如何提高将在后面章节介绍)

  单元测试的目的是用来确保程式的逻辑如你预期的方式执行,而并不是用来验证是否符合客户的需求的!通过单元测试来建立一道坚实的保障,防止代码在日后的修改中不会被破坏掉。

  是不是很失望?单元测试并不是用来验证代码是否符合需求的。

  事实上,单元测试是白盒测试的一种,而且需要开发人员来完成,最好是谁开发的代码就该谁来编写单元测试代码,因为代码的编写者最熟悉该段代码的目的,进而编写出验证该目的是否达到的单元测试代码。

  单元测试并不能用来代替其他测试手段,不过是实践过程中确实会很有效的帮助开发人员自查代码,进而发现一些潜在的BUG。但这只是一个额外的收获,若不是采用TDD那样的测试先行开发方式,那么单元测试的根本目的不是用于也无法检验当前代码是否存在BUG的!

  上面有说到单元测试最好是由开发人员自己来编写,用于验证该段代码是否符合开发者开发的预期要求。这里可能会有个疑问,既然开发者自己已经很清楚自己想要 结果是什么,直接运行一遍代码实际跑一次,通过断点调试不是就可以很方便的验证了嘛?再通过编写代码的形式,甚至比开发这个功能本身更多的代码,去验证这 个方法是否符合编写的目的,不是很傻很笨很累的办法么?

  也许通过一个大家经常会碰到的实际场景能更好的说明:

  一个项目开始,项目经理把需求拆解为若干个模块分发给不同的开发人员去完成。这样每个人可能只熟悉自己的那部分代码。当项目某个阶段开发完成并上线后,可能部分开发人员会离开项目进入别的新项目,留下个别人员继续维护;或者项目下阶段开发新进一大批人员并不熟悉当前项目;当然最常见的是,在修改BUG阶段是无法完全做到谁产生的BUG就安排谁去修改。

那么这时候就会出现一种常见的情况:因为对当前代码要满足的各种目的不熟悉,在修改一个模块或者BUG的时候把原有正确的功能也影响到了!更要命的是,谁也不知道这个BUG出现了,等待测试人员需要去重新发现一遍。

  于是项目经理会发现,每次只要做了代码修改,无论是重构还是功能新增修改,还是修改了BUG,都无法知道当前代码的健壮性,以前编写的东西是否依然正确可用?

  然而如果这个项目在一开始就编写了单元测试的话,我们可以通过方便的自动化单元测试框架运行所有的单元测试,进而检查在此次修改前的所有被单元测试所覆盖的代码是否依然正常运行(符合以前编写的单元测试期望,如果验证通过,则认为原有代码未受到影响)

  由上我们可以看出,单元测试虽然增加了相当大的开发工作量,但对于一个长期不断改进和维护的项目而言,单元测试反而是消减整体成本的一个有效手段,它能及时而准确的发现在代码修改之后,原来对代码要求的功能是否都依然正确满足。

  但这里有个严重缺陷:单元测试无法检测到某个方法修改后是否对其他方法造成了影响,只能检测到被修改的方法本身的原有目的是否被影响(这个将在下面的与集成测试的区别中详解)

  也因此,个人觉得单元测试最适合的场景是基于TDD开发。若需求发生改变,修改了一个方法,而多数情况下也会去修改单元测试代码,因为预期也发生了改变,这个时候又不能检测到对其他代码的影响,这时单元测试意义确实不大。

  单元测试与集成测试的区别是什么?

  多数人其实一直不能很好的区分集成测试和单元测试,甚至不少人一直理解的单元测试只能算是集成测试,但其实两者的概念是完全不同的。

  单元测试测试的对象是每一个独立的方法,而且尽可能的隔离方法和其他方法以及其他外界依赖项;

  集成测试的测试对象是被单元测试检测后的方法与方法之间的调用关系,以及调用执行过程是否符合预期。

  ● 针对项目的一部份或全部进行测试,可以跨越不同的类别与方法,并可直接存取的外部资源。例如: File I/O, 数据库操作, 网络连接, …

  ● 通常做集成测试都会需要先设置(Configure)测试所需的环境,测试完毕后通常要清除测试所产生的残留资料,以利下次测试或避免影响其他整合测试的结果。

    ○ ClassInitialize Attribute

    ○ ClassCleanup Attribute

    ○ TestInitialize Attribute

    ○ TestCleanup Attribute

  以上这些属性常用于集成测试,不能出现在单元测试中。

  单元测试的三大基本要素(Trustworthiness/Maintainability/Readability)

  1、信任你的测试代码结果

    1)你是否能信任你的测试结果?

    2)当它通过,我们有信心说被测试代码一定工作。

    3)当它失败,它一定证明被测试代码是错误的。

4)如果你不断的对测试结果失去信心,那么你也不会继续坚持撰写单元测试。有

    5)许多人搞不清楚单元测试与集成测试的差别,以致于感觉自己写的单元测试过于薄弱而不相信测试的结果。

    6)如果你因为某些原因导致测试失败,直接去改Code或直接去改Test Code都不是好事,你的首要目的是要能找出测试失败发生的主因,而非只是看错误这件事,这样你才能信任你的测试程式。

  2、测试代码的可维护性

1)是否能够持续的维护你的测试程式?

    2)如何有效的降低维护测试程式的成本?

    PS:透过一些Testable Design Pattern 可以有效提升可维护性。例如: Repository Pattern, Service Pattern……

  3、测试代码的可读性

    1)你的测试程式的命名是否易于理解?

    2)当你测试失败时是否能从测试失败的测试方法(TestMethod)明确看出实际失败的原因?

    3)当读取测试数据的人看不懂你的测试,人们就不会执行这些测试、也不会去维护这些测试,久而久之就会越来越恶化。

  Test Driven Development & Unit Test

  写在本文最后,其实我一直觉得单元测试其实是为了TDD开发模式而诞生的,在这种开发模式下使用单元测试完全是非常顺畅的:

  1、根据软件需求文档拆解软件功能,并设计出功能模块划分;

  2、根据需要的功能模块设计出单元测试场景用例,因为此时可以很清晰的知道能够提供什么样的数据,以及需要达到什么样的功能,这对设计单元测试用例已经完 全足够了;

  3、编写单元测试代码,这个时候可以专注于检验这个方法的是否满足设计的要求,此时甚至实际的代码还根本没开发,而.NET 4.0的Dynamic关键字在这里可以得到充分的发挥:调用那些根本都还不存在的方法,却不会导致编译无法通过。

  4、若在编写单元测试过程中,可以预期当前这个方法若需要调用一些其他类或方法的支持,可以通过编写Mock Object来模拟,同样也是无需实现真正的代码,只需要有基本的代码框架或者接口即可。

  5、在为这个方法编写好单元测试代码之后,就可以开始编写实际的代码实现了,因为在之前为了满足Testability的需要,代码已经是基于依赖倒置模 式的了,无需再担心其他需要调用的类或方法是否已经实现或正确实现。在编写好本方法的实现之后就可以通过运行之前的单元测试进行验收了。

  可以看到,若按照以上这种方式进行开发,首先代码的耦合性是非常低的,其次代码的质量也是很高的,最后还会因为代码之间的耦合度低从而降低在开发过程中, 相互制约进度相互影响的可能性。在追查BUG的时候也很有优势:很容易查到BUG是否蔓延。

  反之,对一个Legacy System进行重构使之Testable,再编写单元测试其实工作量不小,实际的收益也不会特别大。

  单元测试的基本概念以及价值就基本讲完,下篇文章将开始介绍Visual Studio 2010中的单元测试工具与环境。


本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

目录
相关文章
|
9天前
|
敏捷开发 前端开发 安全
【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型
【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型
18 0
【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型
|
2天前
|
敏捷开发 Web App开发 测试技术
【软件测试】概念篇 -- 详解(下)
【软件测试】概念篇 -- 详解(下)
|
2天前
|
安全 测试技术 程序员
【软件测试】概念篇 -- 详解(上)
【软件测试】概念篇 -- 详解(上)
|
9天前
|
监控 数据可视化 IDE
python自动化测试实战 —— 单元测试框架
python自动化测试实战 —— 单元测试框架
|
9天前
|
测试技术
测试基础 Junit单元测试框架
测试基础 Junit单元测试框架
18 2
测试基础 Junit单元测试框架
|
9天前
|
安全 测试技术 Go
Golang深入浅出之-Go语言单元测试与基准测试:testing包详解
【4月更文挑战第27天】Go语言的`testing`包是单元测试和基准测试的核心,简化了测试流程并鼓励编写高质量测试代码。本文介绍了测试文件命名规范、常用断言方法,以及如何进行基准测试。同时,讨论了测试中常见的问题,如状态干扰、并发同步、依赖外部服务和测试覆盖率低,并提出了相应的避免策略,包括使用`t.Cleanup`、`t.Parallel()`、模拟对象和检查覆盖率。良好的测试实践能提升代码质量和项目稳定性。
18 1
|
9天前
|
监控 JavaScript 前端开发
【TypeScript技术专栏】TypeScript的单元测试与集成测试
【4月更文挑战第30天】本文讨论了在TypeScript项目中实施单元测试和集成测试的重要性。单元测试专注于验证单个函数、类或模块的行为,而集成测试关注不同组件的协作。选用合适的测试框架(如Jest、Mocha),配置测试环境,编写测试用例,并利用模拟和存根进行隔离是关键。集成测试则涉及组件间的交互,需定义测试范围,设置测试数据并解决可能出现的集成问题。将这些测试整合到CI/CD流程中,能确保代码质量和快速响应变化。
|
9天前
|
IDE 测试技术 持续交付
【专栏】利用Python自动化测试与单元测试框架提升代码质量与效率
【4月更文挑战第27天】本文探讨了Python自动化测试与单元测试框架在提升代码质量与效率中的作用。Selenium、Appium用于Web和移动应用自动化测试,pytest提供强大、易扩展的测试支持。unittest是Python标准的单元测试框架,支持结构化测试用例和丰富的断言。实践中,应制定测试计划,编写高质量测试用例,实行持续集成与测试,并充分利用测试报告。这些工具和策略能有效保障代码质量和提升开发效率。
|
9天前
|
测试技术 开发者
【专栏】测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践
【4月更文挑战第27天】本文探讨了测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践。TDD强调先写测试用例,通过测试推动设计,确保代码质量与可维护性。BDD侧重软件行为和业务价值,提倡使用通用语言描述行为,减少沟通障碍。选择TDD或BDD取决于项目复杂性、团队技能和业务需求。理解两者差异有助于团队做出合适的选择,发挥测试的最大价值。
|
9天前
|
测试技术 API 持续交付
【专栏】Python在自动化测试与单元测试中的应用,强调其简洁语法和丰富库的优势
【4月更文挑战第27天】本文探讨了Python在自动化测试与单元测试中的应用,强调其简洁语法和丰富库的优势。文章分为三部分:首先,阐述自动化测试的重要性及Python的易学性、库支持、跨平台和社区支持;其次,介绍了Python的Unittest标准测试框架和Pytest第三方框架的特点与用法;最后,讨论了Web UI和API自动化测试实践,并提出持续集成、测试金字塔等最佳实践。Python为软件开发的测试环节提供了强大支持,帮助构建更稳定的系统。

热门文章

最新文章