进行测试是很重要的。测试能让我们不费劲地扩展和重构我们的代码。许多开发者遵循测试驱动的开发流程。我相信写测试能让软件开发变得更有趣，并且通常会带来更好的代码。良好设计以及经过测试的系统更容易维护。
在过去的几年里，开发者开始把许多的应用逻辑放到浏览器中，我们也开始写越来越多的JavaScript代码。因为这种语言非常流行，开发者们开始创建用于改善JavaScript开发体验的工具。在这篇文章中，我们将谈论一些专门用于测试客户端JavaScript代码的工具。
测试设置
我们来讨论一下能够进行测试的工具类型，它们能让我们构建、分组以及运行我们的测试。
测试框架
框架包含一些函数如suite、describe、test 或 it。这些能让我们创建测试的分组，这些分组经常被称为套件（suit）。例如：
|
1 2 3 4 5 6 7 8 |
describe('Testing user management', function () { it('should register a new user', function(done) { // the actual testing goes here }); it('should remove a user', function(done) { // the actual testing goes here }); }); |
我们把应用逻辑分割成块，每个块都有自己的套件。该套件包括我们想在代码上运行的相关测试。流行的JavaScript测试框架有QUnit、Jasmine 或Mocha.
声明库
我们用声明库来做实际的检查。它们提供了易用的函数，如下面的例子：
|
1 |
expect(5).to.be.a('number'); |
有很多的模块可供我们使用。Node.js甚至就有一个内置的模块，也有一些开源的工具供我们选择，如Chai、Expect 或 should.js。
应该提醒的是，一些测试框架拥有自己的断言库。
运行器
我们可以需要或者也可以不需要一个运行器（runner）。有些情况下单一的测试框架不能满足，因而我们需要在一个特定的上下文来运行测试。为了完成这件事，我们使用一个运行器。有些情况下这些工具被称为“spec runners”或“test runners.”。这些工具包装了我们的测试套件，并且在一个特殊的环境下运行。我们将会讲到这一点。
应用程序
我们需要一个待测试的应用程序。尽管这只是用于举例说明，但它不能太过简单。TODOMVC 看起来是个不错的选择。它基本上跟其他的TODO app一样，使用了许多不同的框架。我们用Backbone.js 的变种。这就是该应用程序的样子：
假设这是我们上个月在做的一个项目，并且计划下周发布。我们想确保它通过一些测试，也假设后端的已经测试过了。唯一的问题是客户端的JavaScript代码。在这个时候，由于应用程序已经完成了，我们最感兴趣的是它是否能正常地工作。它是一个TODO app，因此我们需要保证用户能够添加、删除以及编辑任务。
在浏览器中测试
我们需要对浏览器中运行的代码执行检查，因此在浏览器中进行测试是很合理的。我们将使用Mocha来作为框架。由于该框架不带断言库，我们将在项目中引用Chai。我们从todomvc.com 下载了app，并且浏览了文件：
|
1 2 3 4 5 6 7 8 9 10 |
├── bower_components ├── js │ ├── collections │ ├── models │ ├── routers │ ├── views │ └── app.js └── bower.json └── index.html └── readme.md |
这篇文章是关于测试的，因此我们不打算深入Backbone.js工作原理的细节。然而，这里介绍一下文件和目录的基本细节：
- bower_components – 包含Backbone.js库、本地存储助手、jQuery、Underscore.js以及TODOMVC通用文件
- js – 这个目录包含这个app的实际代码
- bower.json – 定义项目的依赖
- index.html – 包含HTML标签（模板）
在平常的开发流程中，我们打开一个浏览器、加载应用程序并且使用UI。我们在输入框敲入了一些文字新建了一个TODO，按Enter键然后任务显示在下面。通过点击小小的X标志来移除记录，通过双击TODO来编辑任务。我们有很多涉及不同鼠标事件的动作。
为了测试app，我们不想一遍遍重复上面的步骤。自动化测试可以帮到我们。我们将有效地运行这个应用程序，并且写能够与页面交互就像我们手动操作一样的代码。让我们创建一个tests_mocha文件夹存放我们的测试。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
├── bower_components ├── js │ ├── collections │ ├── models │ ├── routers │ ├── views │ └── app.js ├── tests_mocha │ ├── package.json │ ├── spec.js │ └── TestRunner.html └── bower.json └── index.html └── readme.md |
Mocha和Chai都可以通过npm来安装，npm来自Node.js。我们只需把它们添加到package.json文件，并且在同一个目录下运行npm install。
|
1 2 3 4 5 6 7 8 9 |
// package.json { "name": "project", "version": "0.0.1", "devDependencies": { "chai": "1.10.0", "mocha": "2.1.0" } } |
创建测试运行器
spec.js会包含我们的测试，TestRunner.html 是我们将要修改的副本。我们需要让应用程序跑起来，因此肯定会用到index.html的代码。在讨论改变之前先看一看原始文件是什么样的：
进行测试是很重要的。测试能让我们不费劲地扩展和重构我们的代码。许多开发者遵循测试驱动的开发流程。我相信写测试能让软件开发变得更有趣，并且通常会带来更好的代码。良好设计以及经过测试的系统更容易维护。
在过去的几年里，开发者开始把许多的应用逻辑放到浏览器中，我们也开始写越来越多的JavaScript代码。因为这种语言非常流行，开发者们开始创建用于改善JavaScript开发体验的工具。在这篇文章中，我们将谈论一些专门用于测试客户端JavaScript代码的工具。
测试设置
我们来讨论一下能够进行测试的工具类型，它们能让我们构建、分组以及运行我们的测试。
测试框架
框架包含一些函数如suite、describe、test 或 it。这些能让我们创建测试的分组，这些分组经常被称为套件（suit）。例如：
|
1 2 3 4 5 6 7 8 |
describe('Testing user management', function () { it('should register a new user', function(done) { // the actual testing goes here }); it('should remove a user', function(done) { // the actual testing goes here }); }); |
我们把应用逻辑分割成块，每个块都有自己的套件。该套件包括我们想在代码上运行的相关测试。流行的JavaScript测试框架有QUnit、Jasmine 或Mocha.
声明库
我们用声明库来做实际的检查。它们提供了易用的函数，如下面的例子：
|
1 |
expect(5).to.be.a('number'); |
有很多的模块可供我们使用。Node.js甚至就有一个内置的模块，也有一些开源的工具供我们选择，如Chai、Expect 或 should.js。
应该提醒的是，一些测试框架拥有自己的断言库。
运行器
我们可以需要或者也可以不需要一个运行器（runner）。有些情况下单一的测试框架不能满足，因而我们需要在一个特定的上下文来运行测试。为了完成这件事，我们使用一个运行器。有些情况下这些工具被称为“spec runners”或“test runners.”。这些工具包装了我们的测试套件，并且在一个特殊的环境下运行。我们将会讲到这一点。
应用程序
我们需要一个待测试的应用程序。尽管这只是用于举例说明，但它不能太过简单。TODOMVC 看起来是个不错的选择。它基本上跟其他的TODO app一样，使用了许多不同的框架。我们用Backbone.js 的变种。这就是该应用程序的样子：
假设这是我们上个月在做的一个项目，并且计划下周发布。我们想确保它通过一些测试，也假设后端的已经测试过了。唯一的问题是客户端的JavaScript代码。在这个时候，由于应用程序已经完成了，我们最感兴趣的是它是否能正常地工作。它是一个TODO app，因此我们需要保证用户能够添加、删除以及编辑任务。
在浏览器中测试
我们需要对浏览器中运行的代码执行检查，因此在浏览器中进行测试是很合理的。我们将使用Mocha来作为框架。由于该框架不带断言库，我们将在项目中引用Chai。我们从todomvc.com 下载了app，并且浏览了文件：
|
1 2 3 4 5 6 7 8 9 10 |
├── bower_components ├── js │ ├── collections │ ├── models │ ├── routers │ ├── views │ └── app.js └── bower.json └── index.html └── readme.md |
这篇文章是关于测试的，因此我们不打算深入Backbone.js工作原理的细节。然而，这里介绍一下文件和目录的基本细节：
- bower_components – 包含Backbone.js库、本地存储助手、jQuery、Underscore.js以及TODOMVC通用文件
- js – 这个目录包含这个app的实际代码
- bower.json – 定义项目的依赖
- index.html – 包含HTML标签（模板）
在平常的开发流程中，我们打开一个浏览器、加载应用程序并且使用UI。我们在输入框敲入了一些文字新建了一个TODO，按Enter键然后任务显示在下面。通过点击小小的X标志来移除记录，通过双击TODO来编辑任务。我们有很多涉及不同鼠标事件的动作。
为了测试app，我们不想一遍遍重复上面的步骤。自动化测试可以帮到我们。我们将有效地运行这个应用程序，并且写能够与页面交互就像我们手动操作一样的代码。让我们创建一个tests_mocha文件夹存放我们的测试。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
├── bower_components ├── js │ ├── collections │ ├── models │ ├── routers │ ├── views │ └── app.js ├── tests_mocha │ ├── package.json │ ├── spec.js │ └── TestRunner.html └── bower.json └── index.html └── readme.md |
Mocha和Chai都可以通过npm来安装，npm来自Node.js。我们只需把它们添加到package.json文件，并且在同一个目录下运行npm install。
|
1 2 3 4 5 6 7 8 9 |
// package.json { "name": "project", "version": "0.0.1", "devDependencies": { "chai": "1.10.0", "mocha": "2.1.0" } } |
创建测试运行器
spec.js会包含我们的测试，TestRunner.html 是我们将要修改的副本。我们需要让应用程序跑起来，因此肯定会用到index.html的代码。在讨论改变之前先看一看原始文件是什么样的：
