Jack 同学的作业：

TDD （Test-Driven Development，测试驱动开发）
为什么用TDD？
1、想的更多（我们在开发过程中往往会考虑的不是很周全，看着是完成了功能，实际上却有小的bug存在）
2、便于沟通（开发人员间，更多的是通过代码来交流沟通的。测试用例比开发代码更能明确的指出，系统要做什么）
3、优化设计（我们在开发中应当遵循尽量简单而且行之有效的方法，减少依赖，降低耦合）
4、鼓励重构（传统的重构，每次修改都需要小心翼翼，生怕修改之后，不符合原来的要求，但是一旦有了TDD，就不用担心了）
5、减少失误（增加新功能的时候，往往是一改一大片。但是，如果加入TDD测试，这种大幅度修改会让你很难写好测试，强迫我们去降低修改幅度，每次一点一点的修改）

TDD目的:以测试推动开发进程。

测试框架：JEST

测试工具库：Enzyme

相比于mocha+chai

优点：

1、集成覆盖率检查，减少额外的库

2、jest是fb的亲儿子，有着强力的官方支持。

缺点：

1、感觉上比抹茶慢

相关依赖：
npm install --save-dev jest
npm install --save-dev babel-jest
npm install enzyme --save-dev
npm i --save-dev react-addons-test-utils
jest的配置。可以再package.json中增加：
"jest”:
{
"collectCoverageFrom”:
["**/*.{js,jsx}”,
"!**/coverage/**”,
"!**/dist/**”,
"!**/store.js”,
"!**/provider.jsx”,
"!**/index.js”,
"!**/webpack.config.js”],
"coverageThreshold”:
{"global”:
{
"branches":95,
"functions":95,
"lines":95,
"statements”:95
}
}
}
collectCoverageFrom :忽略的文件

coverageThreshold：文件覆盖率

原则：
1、UI测试的是dom是否生成
2、action测功能性
3、reducer测试值是否正确

../src/views/Demo
import React from ’react’

export default class Demo extends React.Component{
constructor(){
super()
this.handleClick=this.handleClick.bind(this)
}
handleClick(){
console.log(123456)
}
render(){
    return(
    <div>
        <header>
            <h1>demo</h1>
            <a onClick={this.handleClick}>123</a>
        </header>
    </div>
)}
}
Demo.propTypes={
    onClick:React.PropTypes.func.isRequired
}

../test/Demo.test.js
import React from ‘react’
import {shallow} from ‘enzyme’ 
importDemo
 from '../../src/views/Demo’
const props={onClick:jest.fn()}
describe(‘demo component',()=>{
it('should render dom',()=>{
const wrapper = shallow (<Demo{...props}/>) //加载Demo为Dom
expect(wrapper.find('a').text()).toContain(‘123’);//内容包含123的dom
expect(wrapper
.props.children[0].props.children).to.equal(‘demo’);//内容等于demo
})
})
packjson中的依赖关系：
"devDependencies": {

"babel-core": "^6.23.1",

"babel-jest": "^19.0.0",

"babel-loader": "^6.3.2",

"babel-plugin-transform-runtime": "^6.5.2",

"babel-preset-es2015": "^6.22.0",

"babel-preset-react": "^6.23.0",

"babel-preset-stage-0": "^6.22.0",

"babel-runtime": "^6.5.0",

"classnames": "^2.2.3",

"css-loader": "^0.26.2",

"enzyme": "^2.7.1",

"file-loader": "^0.10.1",

"html-webpack-plugin": "^2.28.0",

"jest": "^19.0.2",

"lodash": "^4.17.4",

"react-addons-test-utils": "^15.4.2",

"style-loader": "^0.13.2",

"url-loader": "^0.5.8",

"webpack": "^2.2.1",

"webpack-dev-server": "^2.4.1"

},

"jest": {

"collectCoverageFrom" : [

"**/*.{js}",

"!**/coverage/**",

"!**/dist/**",

"!**/store.js",

"!**/provider.jsx",

"!**/index.js",

"!**/webpack.config.js"

],

"coverageThreshold": {

"global": {

"branches": 95,

"functions": 95,

"lines": 95,

"statements": 95

}

}

}

测试demo的git地址：https://github.com/xuxtc/react-redux-demo.git

Rex - JiangKaiPing 同学

什么是TDD？
TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
TDD自动化测试工具
1、 React Native
2、 Mocha+chai
3、 Jest+Enzyme
主要调研（Jest+Enzyme）（以下来之百度）：
1、和React师出同门，FB官方支持
2、已经集成了测试覆盖率检查、mock等功能，不需要安装额外的库
3、文档完备，官方提供了和babel、webpack集成情况下以及异步调用的测试解决方案
4、官方提供snapshot testing解决方案
上述3个工具差别
1、 React Native偏原生JS代码
2、 Mocha+chai效率快
3、 Jest比Mocha慢一点但师出同门都来自Facebook
Jest的简单安装
1、安装Jest
npm install --save-dev jest
2、如果测试项目中使用babel
npm install --save-dev babel-jest
3、安装Enzyme
npm install enzyme --save-dev
4、如果使用react13以上的版本
npm i --save-dev react-addons-test-utils
5、如果需要忽略一些配置比如store.js和用于合并reducers的index.js在package.json中添加
"jest": {
    "collectCoverageFrom" : [
      "**/*.{js,jsx}",
      "!**/coverage/**",
      "!**/dist/**",
      "!**/store.js",
      "!**/provider.jsx",
      "!**/index.js",
      "!**/webpack.config.js"
    ]
  }
6、给单元测试覆盖率定个目标，达到目标才通过
"jest": {
  "collectCoverageFrom" : [
    "**/*.{js,jsx}",
    "!**/coverage/**",
    "!**/store.js",
    "!**/provider.jsx",
    "!**/index.js",
    "!**/webpack.config.js"
  ],
  "coverageThreshold": {
    "global": {
      "branches": 95,
      "functions": 95,
      "lines": 95,
      "statements": 95
    }
  }
}
7、添加测试命令
"scripts": {
  "test": "jest"
}
8、这样就可以通过npm test来测试代码，但是目前只测试Holle world 通过，测试工程问题还有BUG待解决

David - LiQunBin 同学的作业：

调研TDD前端测试驱动的相关信息
一.与传统开发的区别
正常的开发流程：先开发界面或类，然后在进行编码测试
    即：项目代码开发 -> 编写测试用例 –> 运行测试用例 -> 修复代码BUG
而TDD：首先是进行测试用例的编写，然后再进行类或者用户界面的开发。
   即：编写测试用例 -> 运行测试用例 –> 编写项目代码 -> 运行测试用例 -> 重构代码
二.原理
    测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。
三.特征
    1.与其他代码相隔离：单元测试只测试一件事，否则应该怀疑是否是测试内容有误
       2. 与其他开发人员隔离：保证最小化的变量影响单元测试，也就是控制变量法。逐渐形成了模拟框架以及依赖注入框架等辅助工具。
        3.有针对性：要做有意义的测试，保证完成那些功能或方法。
        4.可重复：单元测试的最大优势就是可重复，这也是持续集成的意义所在。
        5.可预测：单元测试保证的是---确定的输入得到肯定的输出。
四.测试方式
        1.单元测试：针对一个基础类进行输入/输出测试
              主要是工具：NUnit、MSTest
        2.框架测试：测试一个方法而不对其他发展产生影响或者被影响    
               主要工具：Rhino Mock、Type Mock、Moq
五.过程
        制定TODO列表—>快速完成测试用例编写—>测试代码编译不通过—>编写对应功能代码—>测试通过—>重构—>循环开发


然后说了这么多，我并不知道要怎么做这个。
理解：就是将主要功能用简单的demo先做出效果，从而预测项目效果

Blue - ZhongXiuJuan 同学的作业：

一、什么是TDD？
1、TDD的全称是Test Driver Development，测试驱动开发。
2、它是开发中的一项核心实践和技术，也是一种设计方法论。
3、它的基本思路：通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
4、测试驱动开发是一种开发方法，是开发人员参与的活动。

二、TDD原则？
1、独立测试：不同代码的测试应该相互独立。类、函数、用例等都独立测试。
2、测试列表：任何阶段想添加功能时，应把相关功能点加到测试列表中，然后才能继续手头工作，避免疏漏。
3、测试驱动：要实现某个功能，要编写某个类或某个函数，应首先编写测试代码，明确这个类、这个函数如何使用，如何测试，然后在对其进行设计、编码。
4、可测试性：产品代码设计、开发时的应尽可能提高可测试性。
5、及时重构：对结构不合理，重复等“味道”不好的代码，在测试通过后，应及时进行重构。

三、流程？
测试驱动开发的基本过程如下：
①　快速新增一个测试
②　运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过
③　做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理    的方法
④　运行所有的测试，并且全部通过
⑤　重构代码，以消除重复设计，优化设计结构

四、优缺点？
优点：
1、 首先站在客户方代码的立场，可以获得更好的api。
2、在写代码之前先写测试用例，可以对我们编写代码提供指导性的参考，防止我们漏掉一些功能。
3、在更改代码后测试用例不能通过时，我们可以马上锁定问题位置,缩短排查bug时间。
4、可以改善软件质量，支持重构。
5、用TDD测试覆盖率高，软件做集成测试的时候一般问题会比较少。
      缺点：
      1、它需要我们有设计完备的测试用例的能力,否则你将会吃了亏编写了一大堆测  试用例，却没测到点子上。
      2、增加代码量，测试代码是系统代码的两倍或更多。
      3、可能不适合时间很紧的软件开发，更适合于产品和平台的开发。
问题：
1、初步了解了TDD，知道是什么，有什么作用，但是我们什么时候会用到这个，或者要用的时候需要安装哪些软件？具体怎么操作还是不懂。

JiaWei 同学的作业：

What？
TDD（测试驱动开发）：简而言之就是在编写任何功能代码之前，先写它的测试代码。
步骤：
根据需要编写一个测试用例，代码尽可能的简单；
运行它应该会有失败这个机制；
编写功能代码，让写的测试用例通过；
完善该阶段（单元）的测试用例；
根据功能的增加，编写更多的测试用例；
修改功能代码使新增的测试用例和原来的都通过；
重构，包括功能代码和测试用例；
单元测试的目的显而易见，用来确定是否适合使用，每个单元测试就是一段用于测试一个模块或接口是否能达到预期结果的代码，开发人员需要使用代码来定义一个可用的衡量标准，并且可以快速检验。

Why？
用TDD的方法可以使代码干净（代码重构的结果），测试覆盖率高（先写测试的结果），软件做集成测试的时候一般问题会比较少。而且你敢改人家的代码，看到有fail的test case 证明你有改错人家的东西，看到所有的test case都过了的话，你也很有信心说，我没有改错，或程序不会因为我的改动而挂掉。
每次都是很小的方面出发，从一个小问题开始解决，知道解决一个大问题。俗话说：步子迈大了容易扯蛋，步子迈大了就想得多，不可预知的就多，容易忽视很多小问题。
它可以逼着你提高你的编程习惯、往更好的方面去编写代码，逼着你使用面向对象，提高自己代码的变成技能。

How？
1. 举1个栗子：我需要随机生成四位不重复的随机数
首先我们分析一下我需要的东西：
它是数字；
它是四位的；
它是随机出现的，每次点击生成的都是不同的；
它的每一位都是不同的；
所以：我们再编写测试代码的时候，就要get到以上所有的点。首先，我们可以判断生成数的类型，其次我们可以遍历每一位并且判断每一位的数字有没有重复的（也可以使用正则），最后我们可以生成多条，遍历判断是否多条数据中是否有两个数据相等。如果有一条通不过，那么可以报fail，都通过可以直接success。
2. 举2个栗子：一个除法函数来做例子

Paste_Image.png

显然，将会提示pass通过。但是问题来了，这个测试的用例太单一和普通了，如果使用0做除数呢？或者在实际使用时，产品需要一个0来代替这样一个不符合数学概念的结果去适应必须为数字类型的某种计算，于是division出现了一个bug。
还有，如果用’alert’来做输出，你四不四傻？一个测试用例还好，如果是一个项目的呢？你就不怕你的浏览器奔溃？
所以，代码第二弹来了：

Paste_Image.png

现在可以使用matcher方法添加许多测试用例，并且还能为该用例命名，在页面中直接显示每个用例是否通过。这样一个基本的单元测试就完成了，当然它的覆盖率还远远不够，这里仅作为一个例子。
使用方式：

Paste_Image.png

别人我都不会告诉的话：既然编写了测试代码，你还在傻傻的点击按钮来操作吗？那么你四不四傻的N次方？请使用：document.getElementById('button_id').click();让按钮自己来调用。

工欲善其事必先利其器（内容来源于百度）
原文网址：https://segmentfault.com/a/1190000000317146
JavaScript测试框架：
Jasmine
Qunit
Sinon
Mocha
前端测试工具：
1.  Client/Server测试
i.  JSTD（JavaScript Test Driver）
ii. Karma
iii.    TestSearm
iv. Buster
基于网页测试：
Selenium

React
请参考网址：http://www.jianshu.com/p/6c74c96148c9

PS：
对于“他弟弟”我的内心还是拒绝的。是，每个人都追求能开发出高质量的代码，更少的Bug、更容易维护不仅让人心情愉悦，也让我们有更多时间去学习和生活。（少加一些班，有时间交女朋友）。虽然TDD可以帮我们做到这一些。但是你从代码上节省出来的时间，全用到TDD上去了，具体的数据我不知道，但是身边那么多搞开发的有多少用到了TDD？有多少坚持在用TDD？搞开发，准备一辈子搞开发吗？而且弄TDD你在开发之前就已经想到你的代码该怎么写了，怎么写TDD了，又有多少人能达到？我想说现在用TDD的可能就是为了一个逼格吧。我不反对学习新技术，用DIV+CSS+JS可以开发前端，用React+Redux+JS也可以开发前端。说句很俗的话：你新学一项技能，下一份工作面试的时候可能会多一份机会，但是放眼网去中国招前端的有哪一家公司说需要TDD的呢？是在BTA里面吗？说白了，我进不了BTA，别说什么我没有志气什么什么的话，我觉得我是认清了事实。前端三大技能HTML+CSS+JS这三项吃透了嘛？不可能吃透的，金字塔尖的面积很小，挤不上去的。中间的还有那么多人，你挤得过吗？所以对于他，我还是拒绝的，虽然我还没有开始实施这个东西，但是我觉得比较困难，要想到很多，要将整个项目全部了解，了然于胸。然后花时间去写测试，然后去调试，再修改，然后再调试修改，最好还要重构。看着都头大。
一家之言，不知所云。权当瞎BB。23333333...

XuYang 同学的作业

TDD
  1、    定义：TDD – 测试驱动开发，是敏捷开发的一项核心实践和技术。也是一种设计方法论。设计思路是通过测试来推动整个开发的进行。首先编写单元测试用例代码来确定需求，去掉不确定的需求。
  2、    优点：节省开发的时间，明确需求。保证代码的健壮性。
  3、    缺点：代码量大。前期准备过多。需求开发要求比较高。
  4、    结论：TDD思想是从项目开始之初就进行，不太适用目前的项目。

单元测试
  1、    单元测试：是指对软件中的最小可测试单元进行检查和验证
  2、    优点：保证代码质量。规模小，易于隔离定位错误。降低测试成本。
  3、    缺点：增加学习成本，增加代码工作量。
  4、    必要性：
  a)    保证代码正确性
  b)    解释性，对其他人员接受代码阅读api提供条件
  c)    保证重构
  5、    结论：单元测试是必要的。

前端单元测试：（资料摘自http://www.admin10000.com/document/6457.html）
　1.为什么需要单元测试
    •   正确性：测试可以验证代码的正确性，在上线前做到心里有底
    •   自动化：当然手工也可以测试，通过console可以打印出内部信息，但是这是一次性的事情，下次测试还需要从头来过，效率不能得到保证。通过编写测试用例，可以做到一次编写，多次运行
    •   解释性：测试用例用于测试接口、模块的重要性，那么在测试用例中就会涉及如何使用这些API。其他开发人员如果要使用这些API，那阅读测试用例是一种很好地途径，有时比文档说明更清晰
    •   驱动开发，指导设计：代码被测试的前提是代码本身的可测试性，那么要保证代码的可测试性，就需要在开发中注意API的设计，TDD将测试前移就是起到这么一个作用
    •   保证重构：互联网行业产品迭代速度很快，迭代后必然存在代码重构的过程，那怎么才能保证重构后代码的质量呢？有测试用例做后盾，就可以大胆的进行重构
　　2.前端相关的单元测试技术
　　2.1 测试框架
　　目前，前端的测试框架很多，像QUnit、jasmine、mocha、jest、intern等框架，这些框架各有特点，简单描述下，感兴趣的可以具体研究：
    •   Qunit: 该框架诞生之初是为了jquery的单元测试，后来独立出来不再依赖于jquery本身，但是其身上还是脱离不开jquery的影子
    •   jasmine: Behavior-Drive development(BDD)风格的测试框架，在业内较为流行,功能很全面，自带asssert、mock功能
    •   mocha: node社区大神tj的作品，可以在node和browser端使用，具有很强的灵活性，可以选择自己喜欢的断言库，选择测试结果的report
    •   intern: 看官方介绍该测试框架功能极其全面，似乎囊括了业内跟测试相关的所有功能
    　　2.2 断言库
    •   chai：应该是目前组流行的断言库了，支持TDD(assert)、BDD(expect、should)两个风格的断言库
    •   var chai = require('chai'); 
    •   
    •   var assert = chai.assert; // typef assert === 'object'
    chai.should(); // 对Obejct.prototype进行拓展
    •    should.js: TJ的另外一个开源贡献
    •   expect.js:BDD风格的另外一个断言库，基于should.js,是mini版的BDD库
    •   assert(node自带核心模块): 可以在node中使用的断言模块
　　2.3 mock库
　　先来说说为什么需要mock吧：需要测试的单元依赖于外部的模块，而这些依赖的模块具有一些特点，例如不能控制、实现成本较高、操作危险等原因，不能直接使用依赖的模块，这样情况下就需要对其进行mock，也就是伪造依赖的模块。例如在使用XMLHttpRequest时，需要模拟http statusCode为404的情况，这种情况实际很难发生，必然要通过mock来实现测试。
    •   sinon.js: 目前使用最多的mock库，将其分为spies、stub、fake XMLHttpRequest、Fake server、Fake time几种，根据不同的场景进行选择。
    　　2.4 test runner
    •   karma: 设置测试需要的框架、环境、源文件、测试文件等，配置完后，就可以轻松地执行测试。
    　　3.单元测试技术的实现原理
    1.  测试框架：判断内部是否存在异常，存在则console出对应的text信息
    2.  断言库：当actual值与expect值不一样时，就抛出异常，供外部测试框架检测到，这就是为什么有些测试框架可以自由选择断言库的原因，只要可以抛出异常，外部测试框架就可以工作。
    3.  mock函数：创建一个新的函数，用这个函数来取代原来的函数，同时在这个新函数上添加一些额外的属性，例如called、calledWithArguments等信息
如何写单元测试用例
　1原则
    •   测试代码时，只考虑测试，不考虑内部实现
    •   数据尽量模拟现实，越靠近现实越好
    •   充分考虑数据的边界条件
    •   对重点、复杂、核心代码，重点测试
    •   利用AOP(beforeEach、afterEach),减少测试代码数量，避免无用功能
    •   测试、功能开发相结合，有利于设计和代码重构
　2 TDD
　　一句话简单来说，就是先写测试，后写功能实现。TDD的目的是通过测试用例来指引实际的功能开发，让开发人员首先站在全局的视角来看待需求。具体定义可以查看维基;
　　就个人而言，TDD不是一个技术，而是一种开发的指导思想。在目前互联网的开发环境下，业务开发很难做到TDD开发，一是因为需要更多时间编写单元测试用例；二是要求非常了解业务需求；三是要求开     发人员有很强的代码设计能力。但是当我们写组件、工具方法、类库的时候，TDD就可以得到很好地使用。
　3 BDD
　　行为驱动开发要求更多人员参与到软件的开发中来，鼓励开发者、QA、相关业务人员相互协作。BDD是由商业价值来驱动，通过用户接口(例如GUI)理解应用程序。详见维基.
React测试
  1、测试工具库
    官方测试工具库
    第三方封装的Enzyme
        推荐使用第三方库Enzyme。React测试必须使用官方的测试工具库，但是它用起来不够方便，所以有人做了封装，推出了一些第三方库，其中Airbnb公司的Enzyme最容易上手。
  2、Enzyme 用法
        Enzyme 模拟了jQuery的API，非常直观，易于使用和学习。它提供三种测试方法。
       shallow
       render
       mount
  摘自（http://www.ruanyifeng.com/blog/2016/02/react-testing-tutorial.html）
    4.1 shallow
    shallow方法就是官方的shallow rendering的封装。
  4.2 render
    render方法将React组件渲染成静态的HTML字符串，然后分析这段HTML代码的结构，返回一个对象。它跟shallow方法非常像，主要的不同是采用了第三方HTML解析库Cheerio，它返回的是一个Cheerio实例对象。
  4.3 mount
    mount方法用于将React组件加载为真实DOM节点。
    4.4 API
    下面是Enzyme的一部分API，你可以从中了解它的大概用法。
       .get(index)：返回指定位置的子组件的DOM节点
       .at(index)：返回指定位置的子组件
       .first()：返回第一个子组件
       .last()：返回最后一个子组件
       .type()：返回当前组件的类型
       .text()：返回当前组件的文本内容
       .html()：返回当前组件的HTML代码形式
       .props()：返回根组件的所有属性
       .prop(key)：返回根组件的指定属性
       .state([key])：返回根组件的状态
       .setState(nextState)：设置根组件的状态
       .setProps(nextProps)：设置根组件的属性

    Demo
    $ git clone https://github.com/ruanyf/react-testing-demo.git
    $ cd react-testing-demo && npm install
    $ npm start


框架测试：（摘自：http://www.ruanyifeng.com/blog/2015/12/a-mocha-tutorial-of-examples.html）
  推荐使用Mocha （摩卡）
  示例
    $ git clone https://github.com/ruanyf/mocha-demos.git
    $ cd mocha-demos
    $ npm install
    $ npm install --global mocha

    测试脚本的写法
      Mocha的作用是运行测试脚本，首先必须学会写测试脚本。所谓"测试脚本"，就是用来测试源码的脚本。
      下面是一个加法模块add.js的代码。

      // add.js
      function add(x, y) {
        return x + y;
      }

      module.exports = add;
      要测试这个加法模块是否正确，就要写测试脚本。
      通常，测试脚本与所要测试的源码脚本同名，但是后缀名为.test.js（表示测试）或者.spec.js（表示规格）。比如，add.js的测试脚本名字就是add.test.js。

      // add.test.js
      var add = require('./add.js');
      var expect = require('chai').expect;

      describe('加法函数的测试', function() {
        it('1 加 1 应该等于 2', function() {
          expect(add(1, 1)).to.be.equal(2);
        });
      });
      上面这段代码，就是测试脚本，它可以独立执行。测试脚本里面应该包括一个或多个describe块，每个describe块应该包括一个或多个it块。
      describe块称为"测试套件"（test suite），表示一组相关的测试。它是一个函数，第一个参数是测试套件的名称（"加法函数的测试"），第二个参数是一个实际执行的函数。
      it块称为"测试用例"（test case），表示一个单独的测试，是测试的最小单位。它也是一个函数，第一个参数是测试用例的名称（"1 加 1 应该等于 2"），第二个参数是一个实际执行的函数。
断言库的用法
    上面的测试脚本里面，有一句断言。

通配符
  命令行指定测试脚本时，可以使用通配符，同时指定多个文件。

  $ mocha spec/{my,awesome}.js
  $ mocha test/unit/*.js
  上面的第一行命令，指定执行spec目录下面的my.js和awesome.js。第二行命令，指定执行test/unit目录下面的所有js文件。
  除了使用Shell通配符，还可以使用Node通配符。

  $ mocha 'test/**/*.@(js|jsx)'
  上面代码指定运行test目录下面任何子目录中、文件后缀名为js或jsx的测试脚本。注意，Node的通配符要放在单引号之中，否则星号（*）会先被Shell解释。
  上面这行Node通配符，如果改用Shell通配符，要写成下面这样。

  $ mocha test/{,**/}*.{js,jsx}
测试用例的钩子
    Mocha在describe块之中，提供测试用例的四个钩子：before()、after()、beforeEach()和afterEach()。它们会在指定时间执行。

YangGuang 同学的作业：

今天主要调研的什么是TDD，TDD常用的框架以及相应的特点。具体如下:
1.什么是TDD？
通过维基百科介绍，TDD即Test-Driven Development，测试驱动开发，是来源于敏捷开发的一个极限编程思想。大概来说，就是开发之前，先写测试用例(test case)，然后再实现需要实现的方法或功能，然后跑测试用例，看是否通过。将来增加新功能的时候，也是遵循上述流程，如果所有的test case都通过，那么可以保证代码质量。

2.什么是BDD?
BDD是Behavior-Driven Development，行为驱动开发，相比TDD，BDD更关注通过测试，观察到程序的行为是否正确，因此它的接口行为是使用describe。而与BDD相比，TDD更偏重与测试代码的功能是否实现正确，它的接口是suite。suite是一组测试用例的集合，可用于对测试用例进行分类。suite里面可以嵌套suite，就像测一个功能的一组测试例子里面再细分测不同小功能的测试例子。

3.好的单元测试应该有哪些特点？
(1)简单易懂，每次使用就知道是在做什么，能得到什么样的测试结果。
(2)高覆盖率，重构时更有信心。
(3)运行速度快，不要有额外的工作，例如复杂的环境依赖。

4.对比两种测试框架 JEST 与 Mocha。
JEST特点: 
(1)Facebook 官方支持
(2)自动的让测试并行运行，提高在大项目下测试效率
(3)已集成了测试覆盖率检查、mock、spy等功能，并不需要安装额外的库
(4)文档完备，官方提供了和babel、webpack集成情况下以及异步调用的测试解决方案
(5)官方提供snapshot testing解决方案
(6)相比于Mocha运行速度稍慢
(7)附带的JSDom可以让代码在浏览器里面编写测试
Mocha:
(1)简单、易上手
(2)支持TDD、BDD等多种接口
(3)支持同步和异步的测试
(4)支持多种方式导出结果
(5)支持直接在浏览器上跑JavaScript代码

Mocha + chai 配置测试用例步骤:
(1)在项目根目录下运行 npm init，此时会自动生成package.json的配置文件，期间会需要输入一些信息，比如:
name: (项目根目录) sunshine
version: (1.0.0) 
description: Mocha test
entry point: (index.js) 
test command: (mocha) 
git repository: 
keywords: mocha
author: Sunshine
没有就回车带过

(2)在项目中安装mocha和chai，执行命令npm install - -save-dev mocha chai（前提是电脑里面必须有node）, 然后会在根目录下生成node_modules文件夹

(3)一般把我们所编写的代码放到src里面, 然后将测试代码放置在test目录下(两个目录都需要在根目录下新建), 并按照命名规则来清晰地对应测试代码和所被测试代码之间的关系，比如 src下的 add.js, test下的 add.test.js就存在对应关系。

(4)编写add.js :
function add (a, b) { return (a+b);}
module.exports = add
编写add.test.js
var add = require(“../src/add.js”); 
var expect = require('chai').expect; 在第二步装好
describe('加法函数的测试', function() {
  it('1 + 2 must = 3', function() {
    expect(add(1, 2)).to.be.equal(3);
  });
});
此处describe是测试套件(test suite), it为单独的测试，是测试的最小单位，称为测试用例(test case)。

至此，初步的测试已经搭建完成，运行mocha即可得到测试结果，需要补充说明以下几点:
1.Mocha默认运行test子目录里面的测试脚本，所以一般把测试文件放在test文件夹下，因此可以省略参数而使用mocha，但是默认情况下仅仅执行test子目录下面的第一层测试用例，不会执行更下层的用例，除非增加- -recursive参数

2.如果需要执行其他文件夹及其子目录的测试，需要在test的mocha.opts里面增加这个文件夹的名字，不过这样就不执行test里面的测试脚本了。

3.mocha.opts可以配置mocha的命令行参数，比如- -reporter / - R 报告格式 - -growl / -G 输出到桌面 - - watch / -w 监视指定脚本，只要指定的脚本有变化，就会自动执行 - -bail / -b  只要有一个测试用例没有通过，就停止执行后面的测试用例 - - grep -g 用于搜索测试用例的名称，然后只执行匹配的测试用例 - -invert / -i 参数表示只运行不符合条件的测试脚本, 必须与- - grep 参数配合使用

4.ES 6测试，需要先安装Babel，执行命令npm install babel-core babel-preset-es2015 —save-dev，然后在项目目录下面新建 .babelrc配置文件，并写入{ “presets” ：[“es2015”] }, 最后使用 - -compilers参数指定测试脚本的转码器，采用
../node_modules/mocha/bin/mocha --compilers js:babel-core/register
以上命令表明测试之前，先用babel-core/register模块。处理一下.js文件，如果全局安装了，就可以使用全局的mocha，此时可以得到测试结果。

5.异步测试
Mocha默认每个测试用例最多执行2000毫秒，如果到时没有得到结果，就报错。对于异步操作，这个时间往往是不够的，需要使用-t或- -timeout参数指定超时门槛，测试用例有一个done函数用于告诉Mocha测试结束了，否则会一直等到超时报错。例如：mocha -t 10000 async.test.js

6.mocha内置对Promise的支持，允许直接返回Promise，等到它的状态改变，再执行断言，而不用显式调用done

7.测试用例的钩子
before() : 在本区块的所有测试用例之前执行
after() : 在本区块的所有测试用例之后执行
beforeEach() 在本区块的每个测试用例之前执行
afterEach() 在本区块的每个测试用例之后执行

8.测试用例的管理:
可以采用 only指定执行某个测试用例，而不执行其他，也可以用skip跳过某个测试用例的执行

9.浏览器测试: 采用mocha init xxx文件夹就会在xxx文件下下面生成 index.html mocha.css mocha.js tests.js四个文件
新建一个源文件 add.js 只写一个函数 add 表示两数相加，把这个源文件和断言库chai.js 加入到index.html，然后在tests.js里面写入测试脚本，然后在浏览器里面打开index.html，就可以看到脚本运行结果。