前端单元测试探索
虽然很多公司有自己的测试部门，而且前端开发大多不涉及测试环节，但鉴于目前前端领域的快速发展，其涉及面越来越广，前端开发者们必然不能止步于目前的状态。我觉得学会编写良好的测试，不仅仅有利于自己整理需求、检查代码，更是一个优秀开发者的体现。
首先不得不推荐两篇文章：
· 前端自动化测试探索
· 测试驱动开发（TDD）介绍中的误区
Intro
单元测试到底是什么？
需要访问数据库的测试不是单元测试
需要访问网络的测试不是单元测试
需要访问文件系统的测试不是单元测试
--- 修改代码的艺术
我们在单元测试中应该避免什么？
· 太多的条件逻辑
· 构造函数中做了太多事情
· too many全局变量
· too many静态方法
· 无关逻辑
· 过多外部依赖
TDD(Test-driven development)
测试驱动开发（TDD），其基本思路是通过测试来推动整个开发的进行。
· 单元测试的首要目的不是为了能够编写出大覆盖率的全部通过的测试代码，而是需要从使用者(调用者)的角度出发，尝试函数逻辑的各种可能性，进而辅助性增强代码质量
· 测试是手段而不是目的。测试的主要目的不是证明代码正确，而是帮助发现错误，包括低级的错误
· 测试要快。快速运行、快速编写
· 测试代码保持简洁
· 不会忽略失败的测试。一旦团队开始接受1个测试的构建失败，那么他们渐渐地适应2、3、4或者更多的失败。在这种情况下，测试集就不再起作用
IMPORTANT
· 一定不能误解了TDD的核心目的！
· 测试不是为了覆盖率和正确率
· 而是作为实例，告诉开发人员要编写什么代码
· 红灯（代码还不完善，测试挂）-> 绿灯（编写代码，测试通过）-> 重构（优化代码并保证测试通过）
大致过程
1、需求分析，思考实现。考虑如何“使用”产品代码，是一个实例方法还是一个类方法，是从构造函数传参还是从方法调用传参，方法的命名，返回值等。这时其实就是在做设计，而且设计以代码来体现。此时测试为红
2、实现代码让测试为绿
3、重构，然后重复测试
4、最终符合所有要求：
· 每个概念都被清晰的表达
· Not Repeat Self
· 没有多余的东西
· 通过测试
BDD(Behavior-driven development)
行为驱动开发（BDD），重点是通过与利益相关者的讨论，取得对预期的软件行为的清醒认识，其 重点在于沟通
大致过程
1、从业务的角度定义具体的，以及可衡量的目标
2、找到一种可以达到设定目标的、对业务最重要的那些功能的方法
3、然后像故事一样描述出一个个具体可执行的行为。其描述方法基于一些通用词汇，这些词汇具有准确无误的表达能力和一致的含义。例如， expect , should , assert
4、寻找合适语言及方法，对行为进行实现
5、测试人员检验产品运行结果是否符合预期行为。最大程度的交付出符合用户期望的产品，避免表达不一致带来的问题
测试的分类 & 测试工具
分类
· API/Func UnitTest
测试不常变化的函数逻辑
测试前后端API接口
· UI UnitTest
页面自动截图
页面DOM元素检查
跑通交互流程
工具
· Mocha + Chai
· PhantomJS or CasperJS or Nightwatch.js
· selenium
with python
with js
mocha + chai 的API/Func UnitTest
mocha是一套前端测试工具，我们可以拿它和其他测试工具搭配。
而chai则是BDD/TDD测试断言库，提供诸如expect这样的测试语法
