众所周知，单元测试功能是组件库开发中不可或缺的一部分，负责检查和验证，保证组件的合理性和规范性。这篇文章主要讲一下单元测试在NUTUI组件库中的探索与实践。我们将详细介绍如何编写单元测试、持续集成服务和Coveralls自动测试代码覆盖率。如图：如果你对这些内容感兴趣，就跟我一起来看看吧！单元测试配置在进入单元测试配置正文之前，我们先了解一下下面两个问题。什么是单元测试？为什么需要单元测试？什么是单元测试？单元测试（unittesting）可以检查和验证软件中最小的可测试单元，是软件开发的重要组成部分。它使添加新功能和跟踪问题变得更加容易。为什么需要单元测试？单元测试在开发过程中非常有用，不仅可以帮助开发人员思考如何设计一个组件，还可以重构一个已有的组件。每次代码更改时都会运行它们。通过单元测试，我们可以放心地交付自己的代码而无需担心。组件单元测试有以下优点：提供描述组件行为的文档，减少调试时间，节省人工测试时间，减少开发新功能时的bug，检测功能中隐藏的bug，减少隐藏的bug，快速定位bug，方便重构，确保code重构的安全如何写单元测试？我们不仅是单元测试的受益者，也是开发者。接下来进入正题，说说如何给vue组件库添加单元测试。单元测试用到的工具大致分为三部分：测试框架、测试运行器、断言库。测试框架因为我们是一个vue组件库，所以我们使用VueTestUtils作为测试框架。它是Vue组件单元测试的官方库。它具有详细的测试指南和自定义设置。文档清晰易用。我们将其作为开发依赖安装在项目中：npminstall--save-dev@vue/test-utils依赖于浏览器环境，可以在真实浏览器或Node虚拟浏览器中运行，因为在不同平台上启动真实浏览器网络更复杂。所以我们让它运行在Node虚拟浏览器中，这就需要JSDOM来帮助我们在Node虚拟浏览器环境中运行测试。我们安装JSDOM作为开发依赖：npminstall--save-devjsdomjsdom-global然后在项目根目录创建/test的空文件夹，在require('jsdom-global')()中创建setup.js文件测试入口处使用jsdom-global手动设置JSDOM。这将在每次运行单元测试时执行setup.js文件，从而引入JSDOM。测试运行器测试运行器是运行测试的程序。测试跑器很多，VueTestUtils基本可以支持主流的JavaScript测试跑器。更好的是，VueTestUtils为我们筛选了它并向我们推荐了两个测试运行器。我们可以选择其中之一。Jest：最全面的测试运行器。它需要最少的配置，默认安装JSDOM，内置断言，命令行用户体验非常好。mocha-webpack：webpack+Mocha的包装器，包括流畅的界面和监听器模式。测试单文件组件的策略是通过webpack编译所有的测试文件，然后在testrunner中运行。使用mocha-webpack的好处是我们可以通过webpack+vue-loader得到完整的单文件组件支持，而且我们不用去编辑源码不妥协，同时Jest也提供了vue-jest预处理器来处理最常见的单文件组件，它仍然不是vue-loader所做的100%。所以我们选择了mocha-webpack。通过npm安装mocha和mocha-webpack：npminstall--save-devmochamocha-webpack需要注意的是，mocha-webpack依赖webpack和mocha，对版本有要求。webpack版本需要4.x.x，mocha版本是4.x.x&5.x.x。断言库我们在使用mocha进行测试时，需要配合断言库使用。Mocha没有像Jest框架那样内置断言库。它允许我们自己选择合适的断言库。expect是一个断言库。其极简的BDD风格得到了众多测试框架的认可。这些测试框架也内置了expect断言库，所以我们这次也使用expect断言库。首先安装开发依赖：$npminstall--save-devexpect并在test/setup.js中写入：global.expect=require('expect')使其全局可用，这样就不需要在每次测试中文件立即导入。安装各种开发依赖后，在根目录package.json文件中定义一个npmscripttest命令{..."scripts":{..."test":"cross-envNODE_ENV=testmocha-webpack--webpack-configdist_cli/webpack/test.config.js--requiredist_cli/test/setup.jssrc/packages/*/__test__/**.spec.js"},...}值得注意的是，如果项目没有交叉-envinstalled，需要先安装，用于跨平台设置环境变量。下面简单了解一下测试命令参数的含义：--webpack-config：指定测试使用的webpack配置文件。--require：确保文件test/setup.js在任何测试之前运行，以便我们可以在该文件中设置测试所需的全局环境。最后一个参数src/directory：是测试包覆盖的所有测试文件的集合。准备好以上环境后，在命令行执行npmtest进行测试。效果如下：最基本的单元测试已经配置完成，但是我们的工作还没有结束，继续往下看增加单元测试代码覆盖率覆盖率不仅是衡量测试完整性的手段，也是一个衡量测试的有效性。测试覆盖率是衡量测试完整性的指标。Mocha是JavaScript项目的测试工具，Istanbul是JS测试覆盖率报告的生成器。我们使用两者来测试代码并为代码库生成测试覆盖率报告。nyc是伊斯坦布尔的命令行界面，我们在项目中安装它作为开发依赖：$npminstall--save-devnyc然后在上面的npm中添加nyc{..."scripts":{..."test脚本“：”跨环境NODE_ENV=testnycmocha-webpack--webpack-configdist_cli/webpack/test.config.js--requiredist_cli/test/setup.jssrc/packages/*/__test__/**.spec.js"},...}还需要在package.json中配置nyc:{..."nyc":{"include":["../../../src/packages/**/*.vue"],"reporter":["lcov","text"],"instrument":false,"sourceMap":false},...}介绍参数含义：包括：reporter测试文件路径:输出lcov(lcov.info+htmlreport)andtextcoveragereportinstrumentandsourceMap:settofalse,disablenyctoinstrumentingandsourceMapyourcode,然后我们指定加载器来完成。这时候我们可以运行npmtest命令来获取代码库的测试覆盖率报告。如图所示，有多个Unknowns，显然存在一些问题。我们需要安装istanbul-instrumenter-loader，然后将加载器添加到我们的test.config.ts配置文件中。然后将生成的环境的配置文件package.conf.ts导入merge。从'../common/dic'导入{ROOT_PACKAGE_PATH}；从'./package.config'导入{packageConfig}；从'webpack-merge'导入合并；module.exports=merge（packageConfig（false），{模块：{规则：[{测试：/\.(js|ts)/，使用：{loader：'istanbul-instrumenter-loader'，选项：{esModules：true}}，包括：[ROOT_PACKAGE_PATH('src/packages')]},{测试:/\.css$/,使用:['style-loader','css-loader',]},{测试:/\.scss$/,使用:['style-loader','css-loader',{loader:'sass-loader',options:{prependData:`@import"@/styles/index.scss";`}}]}],},devtool:'inline-cheap-module-source-map',externals:[require('webpack-node-externals')()]//忽略node_modules文件夹中的所有模块});So至此，整个项目的代码覆盖率统计配置基本完成。值得注意的是istanbul-instrumenter-loader需要放在最上面，保证最后执行。这时候我们在终端执行npmtest就会显示测试覆盖率结果。在项目根目录下，会自动创建覆盖文件夹，里面包含生成的测试覆盖报告文件（icov.info+html）。接下来，我们还将介绍持续集成服务。持续集成服务持续集成是指只要代码发生变化就自动运行构建和测试，并反馈运行结果。在确保符合预期后将新代码集成到主干中，有助于提高项目质量。通过持续集成实现项目的自动编译、打包、签名，结合单元测试实现持续集成+自动化测试。我们的项目维护在Github上。Github有一个好朋友TravisCI，这是一个在线托管的分布式持续集成服务，我们可以使用它来构建和测试托管在Github上的软件项目。您可以轻松地将您的Github项目与TravisCI同步，并且您可以在几分钟内测试您的项目。值得注意的是，TravisCI分为免费和自费两种。对于我们Github上的开源项目，可以直接使用免费版，访问免费版即可。让我们来看看如何使用TravisCI测试你的Github项目。首先访问TravisCI，使用项目的Github账号登录。登录后Travis代表你的Github授权，Travis可以访问你Github上的所有代码仓库。选择需要TravisCI帮你持续集成的仓库，点击右边的激活开关。这样，TravisCI就会帮你监控这个仓库的所有变化，并自动构建它来完成预定的操作。接下来，我们需要在我们的代码仓库的根目录下添加一个.travis.yml文件来告诉TravisCI定义预定的命令，它会告诉TravisCI做什么以及如何做。配置如下内容，可根据需要更改：sudo:requiredlanguage:node_jsnode_js:-'8'script:-npmtest-npmruncoverallsTravis的运行过程非常简单，包括两个阶段：install（安装依赖）和脚本（执行脚本）。对于Node项目，install和script阶段都有默认的脚本，如果不需要修改可以省略。理解参数含义：sudo:required表示需要sudo权限。language：指定项目的语言，node_js指定运行环境为Node。node_js：指定Node版本，可以指定多个。install：安装依赖，用于指定安装脚本，默认脚本为npminstallscript：用于指定构建或测试脚本，默认脚本为npmtest。参数还有很多，我就不一一列举了。具体可以查看官网配置。完成以上操作后，将此文件推送到你的Github仓库。之后，每次将代码推送到Github仓库，Travis都会找到这个文件，并执行配置好的预定义指令。在这里可以看到运行结果，点击查看构建过程详情。如果操作有误，会有如下提示。我们要知道只要在脚本构建阶段出现失败，状态就会显示失败。以上就是TravisCI与Github项目的简单关联过程。TravisCI真的很强大。如果想在Github项目中直接看到CI结果标识，只需点击图标，选择markdown，将结果文本框内容复制到Github上的README.md文件即可。Coveralls自动测试代码覆盖最后我们要生成代码覆盖率报告，这里就需要用到Coveralls了。Coveralls支持Github上的项目，也可以与TravisCI集成。访问https://coveralls.io/，用你的Github账号登录，然后点击上方的AddRepo，然后将按钮设置为ON，点击右侧的detail，点击detials进入详细配置页面，右侧的页面，获取项目的token，根据自己的环境类型编辑相应的配置文件，在根目录下添加.coverall.yml文件，添加如下内容：service_name:travis-cirepo_token:bOzghLfr6hi9x**************56vdl1YG上传到Coveralls测试报告需要有统一的lcov格式。上面我们配置了nyc，在根目录的coverage文件夹下生成lcov.info。在package.json文件的脚本字段中，添加以下命令行“coveralls”：“cat./coverage/lcov.info|coveralls”，将代码推送到Github存储库。同样，我们可以获取到一个测试覆盖标识，进入刚才的详细配置页面。点击按钮将markdown内容复制到Github上的README.md文件中。总结单元测试功能已经集成到我们团队开发的NUTUI组件库中进行实践。NutUI是一个京东风格的移动端Vue组件库，开发和服务于移动Web界面的企业级前中后端产品。通过NutUI，您可以快速构建风格统一的页面，提高开发效率。目前已有近50个组件，广泛应用于京东各项移动服务。后期我们将创新整个NutUI系统架构，提取整个组件库构建工具，使用WebPackNodeAPI构建，对编译进行更细粒度的控制，增加对组件库的优化调整编译配置，大大提高性能。并减少打包文件的大小，并提供独立构建的NutUI-CLI。单元测试的功能也保证了组件的标准化，减少了错误。欢迎使用，如在使用中有任何问题，我们会及时反馈并跟进。流年在笑，未来可期~最后，以上是NUTUI组件库官网，欢迎扫码体验~
