三、单元测试环境搭建
环境搭建比较简单，只需要简单的几步就可以搞定；
1、ide安装
这个根据直接喜好、习惯来安装就可以了，目前我这边使用的是webStorm， 还蛮好用。
2、node安装
本地执行js代码时，需要依赖node环境；下载完之后，直接安装即可。
安装好了之后，设置好环境变量，然后可以在命令窗输入node测试一下:
下载地址：https://nodejs.org/en/download/
3、npm安装
Npm是一个包管理工具，方便下载一些相关的依赖；
我们在安装node的时候，npm也被装上了：可以在命令窗直接输入npm -v测试一下：
4、jest 安装
可以使用npm来安装：
npm i jest -D 安装到本地
npm i jest -g 安装到全局
npm install --save-dev jest 开发依赖模式安装，需要到项目目录下之后，执行命令
如果是成功安装到本地，则在本地会有一个node_modules的文件夹：
本地安装的情况下， Jest命令也只能在当前目录中执行，在其他地方执行会报错。
安装好之后，可以直接执行jest命令, 如图：会执行URL目录下所有带test文件名中的用例，这里会自动采用正则去匹配。
5、jest配置
这里不配置也是可以直接跑起来的，如果需要一些定制的内容，则可以去配置文件中修改或者增加配置；可修改项目根目录下的package.json
四、用例代码结构以及用例文件结构
1、用例代码结构
这里用例编写比较简单，站在不是编写被测试代码的一方，只要了解清楚需求实现，以及详细逻辑实现细节，读懂被测试代码，找出你要检查的点，基本上用例都很简单，前提当然是代码可测；目前我的写法是：一个方法对应一个describe，it方法中的是用例的具体实现；一个describe对应多个用例（it方法），如果被测文件中有多个方法，则用例文件对应多个describe；describe和it以及expect是jest框架中默认的全局变量（https://jestjs.io/docs/zh-Hans/api#describename-fn）。如果没有配置，可能会报语法错误，但是不影响执行，消除错误，可以在文件头加上：/* global describe it expect */，或者在eslint配置文件中进行配置。
2、用例文件结构
用例目录和被测试文件目录结构保持一致，且子目录名一样，用例文件中名字也基本一样，多了一个test，比如：被测试文件名为：index.js，用例名则为：index.test.js；当然这里你也可以使用其他规则去定义你的测试用例目录结构，只要方便查找查看就行。
3、用例开发节奏
实际项目中节奏：由于代码不多，基本上所有测试代码都由测试完成；
（1）底层实现，全部由测试来编写，和开发同步在分支上进行，进度会略慢，有问题的会反馈给开发，基本上手工测试验证完，用例可以开发并调试完成80%左右；
（2）代码上传周期：开发代码上传到分支，并非每天上传，这个需要跟开发沟通好，比如每天下班前提交一次代码。
（3）用例完成之后，以后每次开发再次改动代码必须执行完用例并且通过才能进行合入主干的操作。
可根据时间项目以及要求，动态调整节奏。
五、用例设计思路
六、遇到的问题以及解决办法
1、浏览器依赖
目前大部分的依赖，可以通过jsdom来解决；被测代码中，从浏览器中取值的情况下，基本上都可以解决，比如：url = window.location.href，可以在用例改变jsdom中的全局变量值，然后去重新设置window对象下的属性值；但是仍然有些问题，无法解决：
被测代码中取设置浏览器的某些属性，设置cookie，设置了之后，我们在用例中去调用时，发现取不到cookie，取出来仍然是jsdom的默认值；比如，被测代码中这样写：window.document.cookie = ’name=xx, age=yy‘；这个在浏览器里面执行，然后取出来，完全没有问题，但是在用例中没有什么好办法取到这个值；
如果在用例中设置了window.xx = yy;但是被测代码中将取值放在文件头，或者方法外，时间在取值的时候也是取不到，取到的仍然是jsdom中默认的值。比如如下图这种：UA取到的并不是我们设置后预期想要的。
2、不太好检查的点以及不太适合的做单测的点
在浏览器中加载某个url请求
某些方法调用过于复杂，或者全是涉及到调用，没几行逻辑代码，这里感觉也可以不用做单测。
模块之间耦合太重
函数、方法实现过于长
3、mock 某个方法会提示方法为只读
有个解决办法是：直接mock掉整个文件，然后再mock该方法的返回内容。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
