部署单元测试环境需要做的思考

发表于:2019-2-21 16:08  作者:echizen   来源:github

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 测试环境 单元测试

  18年年末给公司一条业务线部署了单元测试环境。这个项目比较特殊,受众是来自几十位开发者共同开发的近千个模块,有一个预装的开发环境,但是具体到每个模块,就是完全由开发者自己控制的,我们只是提供开发工具,软链到开发环境下。由于项目比较复杂,需要手动配置折腾的东西比较多,而且我们有个库-用类vue语法能同时支持h5端和微信小程序端,测试因此也要针对这种类型的模块提供h5端和小程序端的测试。一番折腾后对于部署单元测试环境感慨良多。
  起步思考清楚需求
  在做这一切之前,先得想清楚自己要搭的这个单测环境需要具备哪些能力。可以先从使用者的角度,譬如我的预期是:
  · 一键化生成单测文件
  · 单测文件中包含基础样本代码,能够测试模块和组件初始化后的data数据结构和ui结构,避免开发者面对一片空白不知从何下手,也保证最基础的能自动做的测试内容由工具来做
  · 测试库mock掉开发框架级别基础库里的需要mock的内容,譬如跳转、分享等封装的功能,并且对通用测试点譬如网络请求、打点等提供封装好的mock函数。让写测试的开发者只用关心自己的代码逻辑,不因为基础库而困扰
  · 开发者在当前模块下调用命令运行测试,终端输出详细的测试报告
  · 测试报告的生成能力
  · 监控文件变更,根据变更生成新的测试结果的能力
  · 对于从vue转小程序的模块,需要一份测试代码,最终能覆盖到h5端和小程序端的测试
  测试框架的能力
  鉴于社区已有这么多成熟的单测框架,没必要手动开发一套单测框架,我们要做的是选套合适的单测框架,并能结合业务特点DIV到能够符合预期功能。
  首先我们来看看一个完善的比较理想的单测框架需要具备哪些能力:
  · 断言库: 且要和社区里常见的几种断言库如Should.js、chai,语法类似,减少开发者学习成本
  · 测试运行库: 能够组织、控制并运行测试,这部分可配置度越高越有利于业务化
  · 测试报告:能清晰的反映测试覆盖率,能定位到为覆盖的代码。即使框架未集成,也是需要测试环境搭建者集成的
  还有一些其他的方便进行测试的功能:
  · 完善的mock方案:对于文件、模块、函数、对象等内容都要有可操作的mock方案
  · 支持异步测试用例:毕竟异步操作会充斥在我们被测试代码的各个地方,对异步的支持是个想需求,而且需求量高,需要越方便使用越佳。
  · 可调控可配置:毕竟要业务化,不能配配参数就能上路,整个测试环节的每一步我们要都能把握调度
  测试流程
  再来看看一个测试运行需要经过哪些步骤,来了解我们需要在哪些环节DIV
  启动测试 - 测试环境初始化 - 被测试文件预处理 - 运行测试 - 获取测试结果 - 结束
  · 测试环境初始化: 这是我们测试框架的代码能和开发者写的模块测试代码通信的一步,我们可以在这里传递测试代码需要的信息,譬如埋下一些全局变量。在这步也可以把测试环境需要做的准备工作做好,譬如源代码基础库的一些处理。
  · 被测试文件预处理:这里是对源代码和测试代码的处理,譬如将源代码的vue代码转化为小程序代码,处理测试文件里的alias等等,需要注意的是这部比较耗时,需要注重优化,并尽量简化
  · 运行测试:提供统一的接口生成组件实例,埋好各种可能需要配置的参数,测试者调用接口运行测试时,就会在你的控制下,生成实例的过程中,可以传递内置的一些信息,处理基础库的内容,挂载实例上的mock方法等等。对于需要h5转化成小程序的模块,需要先测试h5端,再转化成小程序代码,运行小程序端测试,并且封装好的测试框架要保证h5端组件实例和小程序端组件实例上挂载的方法、属性一致,让开发者能用统一的方式测试。
  · 获取测试结果:拿到测试框架返回给我们的结果,视需求处理,譬如是在终端显示,还是作为pre-commit的部分阻止提交,还是在服务器上部署的失败信息回馈。
  选择工具
  搞清楚测试框架的能力和我们需要做的事情,接下来就是要选一款合适的测试框架和一些方便测试的库了,需要考虑以下因素:
  · 可配置、可调控程度:这个非常重要,毕竟要为业务定制,而且业务不停的在发展,需要不停的加功能。可配置、可调控程度限制了你的能力,决定了你的可能性
  · 被测试代码技术栈:这个跟测试框架关系不大,如果是node或者单纯的js,那么都不需要考虑太多。如果是vue技术栈或者react技术栈,就可以选择一些社区里现成的方便测试的库辅助,方便生成组件实例,以及操作组件实例,譬如vue的vue-test-utils, react的enzyme
  · 常用场景:譬如我上面说的异步,如果你的源代码里异步场景比较多,那么选择一款对异步支持友好的代码绝对是开发者的福音。
  测试环境
  在搭建测试环境是,对自己的测试环境要有正确的认知。大多数单元测试都是部署在node端,极少有在浏览器或者微信小程序等真实生产环境下跑的。
  node端的优势是一切都在掌控之中,包括测试框架的调用、测试代码和原代码的处理,不会遇到其他外来未知因素的干扰。
  但是也有限制,譬如node端没有dom,即使用jsdom模拟,但因为jsdom没有css layout, dom节点位置元素丢失。
  所以我们要扬长避短,单元测试毕竟注重的是最小代码单元,对于宏观环境的不利于测试的因素我们可以通过其他方式解决,譬如dom节点位置,缺失,我们可以mock调用dom阶段位置的函数返回结果来模拟,从而不影响到我们业务核心代码的测试。
  个人案例分享
  说了这么多,落地点到我搭建的测试环境,上面所说的期望功能都实现了,方案也在上面叙述了。每个人面对的业务场景不同,还是分享点可以共通的东西,譬如测试框架。
  我选用的是jest,一方面是我个人比较熟悉,另一方面是上面所说的能力其都具备。
  先说说可圈可点之处:
  · jest配置完善,如果用默认配置,就是一个大全家桶,包括测试报告、检测文件变更运行测试这些能力都帮你内置了
  · 虽然默认配置是全家桶,但是可配置性很高,每个单元都可拆卸替换。譬如测试运行库默认用的是jasmine2,但是你也可以换成其他的,一个配置即可完事
  · jest发了22个大版本后,已经比较完善了,这一年看着facebook的这个儿子更新迭代的,还是很靠谱的。
  · 社区繁荣,配套的react测试方案、vue测试方案资料都充足
  用下来觉得不方便的地方:
  · 官方文档只有命令行和配置文件的使用方式,没有任何node端调用的文档,部署环境肯定是node端,这些配置肯定是内置的,导致这些接口参数,包括暴露出的测试调用入口都是通过源码找出来的,非常不方便。
  · 没有测试代码预处理器,只有原被测试代码预处理器,导致如果你需要对测试代码做些处理,都没法方便操作,只能处理后生成文件,再去读取生成后的文件,耗时很长
  · 由于配置了watchman作为检测文件变更的工具,watchman不支持软链,jest内部多出逻辑也没有考虑到软链的情况,如果你的测试环境在一个项目里,被测试文件通过软链链到这个项目里,便没法操作,一定要找到原文件(这个场景比较少)
  搭建单测环境,重要的还是为写测试的开发考虑,让他们用的顺手,提供的api和写法要人性化,消除业务基础库的影响,尽量封装通用的工具函数,还要有完善详细的开发文档。后期就是宣传要给力喽,能够吸引大家来写,毕竟前端领域,非框架类和基础库类的业务代码,很少有人有测试的习惯。

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

【调查报告】你以为的测试行业现状,其实是这样的!

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道