使用Jest在vue项目中进行单元测试的尝试(一)

发表于:2022-1-04 09:17

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:茗远    来源:稀土掘金

分享:
  笔者所在的团队目前正在推进前端自动化测试在项目中的应用,我也在调研和学习中遇到了不少的难题,此篇文章会结合我在学习和实际生产中遇到的问题不断更新。如果你有相关问题,也可以评论留言,我会在工作空闲之余为你解答。在前端自动化测试方面,我也刚刚初出茅庐,希望可以和大家共同进步。
  相关概念
  我们在入门一项技术之前,总要了解一些相关的历史和概念,这样才方便我们知其然也知其所以然,下面我将和大家一起从对自动化测试、单元测试等名词概念的了解开始,同大家一起进入前端自动化测试的世界
  什么是自动化测试
  在软件测试中,自动化测试指的是使用独立于待测软件的其他软件来自动执行测试、比较实际结果与预期并生成测试报告这一过程。 在测试流程已经确定后,测试自动化可以自动执行的一些重复但必要测试工作。也可以完成手动测试几乎不可能完成的测试。对于持续交付和持续集成的开发方式而言,测试自动化是至关重要的。随着软件系统规模的日益扩大,以及应用领域的不断拓展,对软件系统的测试也变得更加困难和复杂,传统的人工测试的局限性也越来越明显。自动化软件测试技术可以克服传统测试技术的许多问题。自动化测试所依据的是一套严密的测试法则和评估标准,具有完整的自动测试过程。因此,它可以避免测试人员惯性思维所导致的测试疏漏,也可减少由于手工测试中繁复的重复工作所导致的人为差错。
  这是来自维基百科中对于自动化的概念的解释,我们可以很清楚的了解,自动化测试的诞生主要是随着项目的扩大,单纯通过人工测试,难以满足对于项目的质量控制,这一点对于回归测试尤为明显。笔者所在的团队维护的一个主要项目同时应用于生产的版本高达100多个。在日常工作中,我们会涉及对某一版本进行迭代,问题修复以及增加新的版本。在这些工作中,无论是前端开发人员还是测试人员都是叫苦不迭。手动的回归测试根本无法满足对于整个项目的回归,而不同的版本难免存在一些耦合现象,回归几个版本很有可能对某些因为代码改动而造成的问题造成测试遗漏,从而导致线上问题的产生。正式因为这些已经造成的历史原因,目前团队已经开始着手进行该项目的重构,我们希望通过更好的版本控制方式,来满足原有的产品需求,同时我们也在重构的过程中着手进行前端自动化测试的引入,来为后续的版本升级甚至再次项目重构提供更好的保障。
  TDD
  测试先行(Test-First) 测试驱动开发(Test-Dricen Development---TDD),TDD是敏捷开发推荐的做法,理论上TDD永远不会有未被测试的代码,这也给开发人员重构现有代码和对应用进行回归测试提供了信心和保障。特别是在程序修改比较频繁时,特别是在程序修改比较频繁时,由于测试用例已经完成,测试期望的结果也是完全可以预料的。
  BDD
  BDD(Behavior-Driven Development) BDD使用用户故事(user story)来描述需求,用户故事通常遵循特定的模板形式
  为什么要选用自动化测试
  自动化测试(尤其是单元测试的自动化),是极限编程和敏捷软件开发的一个关键特征,这也被称为测试驱动开发(TDD)。单元测试的用例可以在代码编写完成之前就设计好,并作为功能的一种定义形式存在。随着新的代码不断完成编写,单元测试随之进行,缺陷被不断找出,因而代码也不断得到改进。由于开发人员能够及时发现缺陷然后立即作出改变,修复的代价大大减小,这种不断发展的开发方式被认为比瀑布模型这类开发结束再测试的方式更为可靠。
  使用单元测试框架(如JUnit、NUnit等“xUnit”类型测试框架)执行自动化测试是目前软件开发行业的大趋势。单元测试框架的应用使得各部分代码开发完成后立即进行相关单元测试来验证它们是否如预期在运行成为可能。
  手工完成一些软件测试的工作(例如大量的低级接口的回归测试)十分艰苦耗时,而且寻找某些种类的缺陷时效率并不高,因而测试自动化,提供一种完成这类工作的有效方法。
  一旦自动化测试方法开发完成,日后的测试工作将可以高效循环完成。很多时候这是针对软件产品进行长期回归测试的高效方法。毕竟,早期一个微小的补丁中引入的回归问题可能在日后导致巨大的损失。
  自动化测试的弊端
  尽管长期来看(尤其是针对回归问题的)自动化测试,可以带来开支上的节省,将所有测试短期内全部自动化还是可能产生巨大的开销,通常情况下业内采用手工测试和自动化测试相结合的方法完成测试工作。
  尽管测试“自动化”了,但测试结果分析、测试脚本维护和编写仍然需要人力投入。
  什么是单元测试
  在计算机编程中,单元测试(英语:Unit Testing)又称为模块测试,是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法。
  通常来说,程序员每修改一次程序就会进行最少一次单元测试,在编写程序的过程中前后很可能要进行多次单元测试,以证实程序达到软件规格书要求的工作目标,没有程序错误;虽然单元测试不是必须的,但也不坏,这牵涉到项目管理的政策决定。
  每个理想的测试案例独立于其它案例;为测试时隔离模块,经常使用stubs、mock或fake等测试马甲程序。单元测试通常由软件开发人员编写,用于确保他们所写的代码符合软件需求和遵循开发目标。它的实施方式可以是非常手动的(透过纸笔),或者是做成构建自动化的一部分。
  单元测试核心内容
  1、测试框架 (类似于代码编写的vue,react)
  2、断言库 (利用断言库来断言产出结果是否符合预期)
  3、mock库 (单元测试的方法,依赖了某些外部数据,利用mock库屏蔽外部方法,外部数据,模拟出一个数值,这个mock库和模拟接口的还不一样)
  4、test runner (运行环境,例如浏览器。这个东西是模拟浏览器环境,来提供单元测试环境)
  5、覆盖率工具 (单元测试通过了,不代表代码没有问题,因为可能是单元测试的覆盖率不足,通过覆盖率工具给出报告来查看测试多少。实际项目无法达到100%覆盖率 70~90% 60%也可以)
  测试框架(两种主流测试框架)
  1、Jest 开箱即用,简单轻松  (大多数公司会采用的测试框架,大而全。)
  2、Mocha 需要自行配置 (完全自定义单元测试,需要采用mocha,纯粹的测试框架,其他的东西需要自己去配,于jest属于两个思想极端)
  断言库
  1、chai 支持所有风格-全面 (jest应用的也是)
  2、assert node环境可以直接使用
  mock库
  sinon (前端基本都在用这个)
  Test runner
  karma (jest 继承)
  覆盖率工具
  Istanbul (行覆盖率,可执行语句的执行比例  函数覆盖率 函数被调用的比例  分支覆盖率 测试if else 分支的多少)
  测试覆盖率
  1、语句覆盖率(statement coverage) 是否每个语句都执行了?
  2、分支覆盖率(branch coverage)是否每个 if 代码块都执行了
  3、函数覆盖率(function coverage) 是否每个函数都调用了?
  4、行数覆盖率(line coverage) 是否每一行都执行了?

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
价值398元的测试课程免费赠送,填问卷领取吧!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2022
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号