Jack Chou's blogjest 测试笔记（一）
测试可让我们对代码更加有信心，测试能保证重构顺利进行等。web 页面自动化测试，一直是行业难点，大家都是手动测试。
随着 node、组件化开发和工程手段在前端的应用，事情开始变好，web 页面的自动化测试越来越容易了。
测试难点
- 环境配置困难
这是当前前端工程化的通病，不仅仅是测试，还有构建、部署等等，都需要配置环境，而且不同的项目，环境配置都不一样，这就导致了学习成本很高。
环境的配置，往往会劝退很多新手。
- 知道如何 mock
比如模拟 http 调用，模拟依赖，模拟定时器等等。
- 不会构造测试用例
适当测试用例可以覆盖到所有的代码，但是测试用例的编写是一个技术活，需要一定的经验。
- 没有测试策略
适当的测试策略可节省大量的测试用例编写时间，但是测试策略的制定也是一个技术活，需要一定的经验。
没有适当的测试策略，会觉得测试很浪费时间，干脆不测试。
- 对业务理解不够深入
对业务理解不够深入，就会导致测试用例编写不够全面，覆盖不到所有的代码。
- 专门讨论前端测试的资料很少
前端开发还处在一个不断发展的阶段，工程化的手段这些年一直在补课，前端测试作为工程化的一部分，也是如此，很多东西都是在摸索中，所以专门讨论前端测试的资料很少。
测试的好处
测试有诸多好处，保证代码质量只是其中一个方面。
- 优化流程
功能开发完毕后，后续的流程都可能发现 bug，而 bug 越是后面发现，修复的成本越高，可能是写这段代码的人离职，后来的人不知道这段代码的作用，也不敢随便改动，甚至写这个代码的人也认识这段代码了，所以测试可以尽早发现 bug，减少后续流程的成本。
- 保证代码质量
大多数的“软件缺陷”并非源自编程错误，对众多从小到大的项目进行的研究而得出的结论往往是一致的：导致软件缺陷的最大原因是产品说明书。——《软件测试》
产品说明书是指需求文档、设计文档等等，这些文档的质量直接影响到代码的质量，而测试可以发现这些文档的问题，保证代码质量。
很多产品经理，只会给出他希望的功能，而不会给出可能的边界情况，开发拿到需求后，很可能也是考虑不周的。
而编写测试，会开发者考虑到更多的边界情况，保证代码质量。
- 保证重构质量
重构是保证代码质量的重要手段，但是重构的过程中，很可能会引入新的 bug，而测试可以保证重构的质量。
没有测试的保证，大家都不敢优化，不敢动代码，能不动就不动，能跑就行。
- 用例即文档
测试用例是对代码的使用方式的描述，而且是最直观的描述，所以测试用例是最好的文档。
- 促使开发者编写可测试的代码
软件测试是一个和开发不同的领域，学习测试可以提升自己的能力：迫使自己编写可测试的代码。
先写测试代码，再实现具体的而功能让测试代码通过，可实现编写最小功能代码的目的。TDD(测试驱动开发)能促使开发者编写最少最干净的代码，让代码具有良好的设计。
前端需要哪些测试
白盒测试
测试代码逻辑和结构，内部实现，往往试开发人员编写。白盒测试往往比较脆弱，因为它和实现耦合，实现改变，测试用例很可能就失败了。
黑盒测试
功能测试，测试功能是否符合预期，不关注内部代码结构。
单元测试（unit test）
测试单一的功能：一个函数、一个接口，是最基础的测试。往往属于白盒测试。
集成测试(integration test)
前端程序需要正常工作，可能需要集成其他模块，比如生产环境中依赖其他资源，需要集成测试。
这种测试配置复杂，生产环境也不好模块，实践中很少做这种测试。
端到端测试(E2E test)
从头到尾验证程序是否正常运行，比如验证后台接口、用户的使用流程等，耗时，性价比不高，实践中往往是测试人员手动测试代替。
有哪些测试框架
小结
- 前端自动化测试还不够普及
- 前端自动化测试的好处很多
- 介绍了前端测试的类型
- 介绍了前端测试的框架