发布于 2015-08-18 16:38:36 | 271 次阅读 | 评论: 0 | 来源: 网络整理
当运行测试时，可以在很多种不同的方案里选取最适合工作流的方案。找到一种摩擦最低的运行测试的方案非常重要，因为测试是一项经常要做的事情。
运行测试的最简单的方法是直接在浏览器中打开页面。下面将展示如何加入一个qunit的测试harness给应用，并可以针对其运行测试：
首先，从这里获取一份qunit（包括Javascript和CSS）。
然后，创建一个HTML文件来包含qunit，如下例所示：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>QUnit Example</title> <link rel="stylesheet" href="qunit.css"> </head> <body> <div id="qunit"></div> <div id="qunit-fixture"></div> <script src="qunit.js"></script> <script src="your_ember_code_here.js"></script> <script src="your_test_code_here.js"></script> </body> </html> |
最后，使用选定的浏览器打开上面的文件。
这样就完成了所有的工作，并且运行了测试。不需要安装和配置其他任何工具，或者运行一个其他的进程。在添加或者修改了测试或者代码后，重载页面即可重新运行测试。
如果这已经满足了需求，那么不需要继续往下读了。但是，如果希望能有一种更加自动化的运行测试的方法，那么请继续往下读。
不停的手动的打开和刷新浏览器，很显然是一件非常乏味的工作。当知道代码可以在所有的浏览器中得到运行，这样能得到更多的利益，不过依然需要在修改代码后手动的启动和刷新来测试。消除重复的劳动本来就是使用计算机的原因之一，因此这里就是一个需要解决的问题。
幸 运地是有工具能帮助我们完成这些工作。这些工具可以在实际的浏览器中运行测试（是浏览器 - 同一时间运行多个），并将测试结果通过一个综合的视图呈现。这些工具都是在命令行中执行的，并且也能在文件发送改变的时候自动重新运行测试。不过相比创建 一个简单的HTML文件，这种方法需要进行一些额外的配置，不过从长远来说这也是能节约时间的。
Testem是一个配置和使用都非常简单的工具。简单地说，其将收集所有应用代码、测试代码、选择的测试框架，并自动创建一个测试"harness"。然后启动每个浏览器（指定的）来运行测试，并将结果返回。Testem有非常好的基于终端的用于显示每个浏览器测试结果的用户接口。testem内置了非常多的特性，目前还没有任何第三方的插件或者扩展。
为了使用testem，需要在node.js中安装testem模块。假设已经安装了node，那么只需要运行如下命令即可：
1 |
npm install -g --save-dev testem |
现在完成一个简单的配置，就可以使用Testem来运行测试了。
1 2 3 4 5 6 7 8 9 10 |
// testem.json
{
"framework": "qunit",
"src_files": [
"your_ember_code_here.js",
"your_test_code_here.js"
],
"launch_in_dev": ["PhantomJS"],
"launch_in_ci": ["PhantomJS"]
}
|
以上就是需要安装和配置的全部内容。现在再详细的回顾一下配置。
framework
QUnit。Testem会完成对QUnit库的加载，因此不需要担心QUnit的加载问题。src_files
testem在运行测试是需要加载的源文件（包括产品代码和测试代码）。launch_in_dev
launch_in_ci
headless的持续集成环境。除以上配置外，testem还提供了更多的参数，如果愿意的话可以进行更详细的配置。可以在testem文档中找到所有可用的配置项的详细说明。
执行下述命令来运行testem。
1 |
testem |
这将启动testem，并且启动所有在launch_in_dev配置的所有浏览器。可以看到一个基于标签的视图，每个标签对应一个浏览器，通过箭头按键可以查看每个浏览器的执行结果。此外还有一些其他的命令，运行testem -h可以查看能在标签视图中使用的所有命令。当src_files指定的文件发生改变时，Testem将持续的运行或者重新运行测试。
launch_in_ci设置在采用如下命令执行testem时生效：
1 |
testem ci |
与运行不带参数的testem非常相似，除了其会使用launch_in_ci取代launch_in_dev设置的浏览器列表外，ci选项会使用相同的配置。ci选项同样会采用testem运行一遍所有的测试，并将测试结果输出到终端。
Karma是另一个易于配置和使用的工具。与testem相似，karma也会收集所有应用代码，测试代码，选用的测试框架，并自动的创建一个测试"harness"。之后也会启动指定的每一个浏览器，运行测试，并生成测试结果报告。其终端用户接口不像testem那么好，不过其会为每一个浏览器生成有颜色的测试结果输出。Karma的插件拥有许多非常有用的特性。如果想了解更多关于编写karma插件的文档可以访问这里。在karma_runner可以获取一些可用的karma插件。
为了开始使用karma，需要安装一些node模块。下面是一个package.json示例文件，其包含了所有karma运行需要的模块。
1 2 3 4 5 6 7 8 9 10 |
// package.json
{
"name": "your_project_name",
"version": "0.1.0",
"devDependencies": {
"karma-qunit": "0.1.1",
"karma-phantomjs-launcher": "0.1.2",
"karma": "0.12.1"
}
}
|
这三个依赖都是karma自己，karma-qunit包含了需要运行qunit测试需要的一切，而karma-phantomjs-launcher是karma测试运行器用来启动一个无头的PhantomJS浏览器来运行测试的模块。还有许多不同的插件用来启动不同的浏览器，包括Google Chrome，Firefox，Safari，IE，甚至Sauce Labs。在Karma Github有一个完整的可用启动器的列表。
现在有了一个包含所有运行karma所需的一切的package.json文件，那么可以运行下面的命令（在package.json文件所在的目录下）来安装这些模块。
1 |
npm install |
现在karma连同所有需要用来开始运行测试的东西都准备就绪了。不过还需要进行一点点额外的配置。如果只需要生成缺省的karma配置，可以执行karma init，这将会在当前目录创建一个名为karma.conf.js的配置文件。配置有许多选项，这里给出一个精简版本的配置：karma需要用来运行测试的最小配置。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// karma.conf.js
module.exports = function(config) {
config.set({
frameworks: ['qunit'],
files: [
"your_ember_code_here.js",
"your_test_code_here.js"
],
autoWatch: true,
singleRun: true,
browsers: ['PhantomJS']
});
};
|
最后还有一样需要安装：Karma命令行接口。
1 |
npm install -g karma-cli |
这就是所有需要安装和配置的全部内容。下面来仔细看看这些配置。
frameworks
QUnit。karma会自动加载QUnit库。files
karma在运行测试时加载。autoWatch
singleRun的值为false时，如果autoWatch值为true表示karma将观察所有files的修改，并重新运行测试。singleRun
true表示将只运行所有测试一次就关闭，如果值为false将运行所有测试一次，当有文件发生改变时，会再次运行所有测试。browsers
除以上配置以外，还有大量的配置项可以用来配置karma。查看karma文档可以看到所有的配置项，除了手动创建karma.conf.js外，还可以运行下面的命令来生成：
1 |
karma init |
启动karma运行：
1 |
karma start |
至于是运行完测试后退出，还是等待文件改变来重新运行测试，取决于配置。
testem和karma都可以与大的构建过程进行集成。例如，项目中可能使用了CoffeeScript，ES6或者其他需要转换源代码到Javascript的某些技术。如果使用了grunt，那么可以为testem使用grunt-contrib-testem，为karma选择grunt-karma来集成到构建过程里。testem和karma都有预处理配置选项。更多关于配置项的信息请查看karma和testem的文档。
通常获取测试结果的不同格式的输出是非常有用的。例如，采用了Jenkins作为持续集成服务器，那么可能就希望获取到XM格式的测试结果，以便Jenkins能够为测试结构生成报表图。此外，也可能希望使用Jenkins一直跟踪测试覆盖率。使用这些测试运行器，可以根据测试结果生成不同格式的报告，对于测试覆盖率的信息也是一样。
为了使testem生成junit xml，只需在运行testem的时候添加一个标志，将输出定向到一个文件即可。
1 |
testem ci -R xunit > test-results.xml |
现在就可以在其他的工具中使用test-results.xml了。
为了使karma生成junit xml，需要安装一个node.js模块。通过下面的命令可以完成模块的安装。
1 |
npm install --save-dev karma-junit-reporter |
当安装上模块后，需要修改karma配置文件来包含下面的配置。
1 2 3 4 5 6 7 |
module.exports = function(config) {
config.set({
/* snip */
reporters: ['progress', 'junit'],
/* snip */
});
};
|
reporters选项决定了测试结果如何返回。progress报告将会显示如下信息。
1 |
PhantomJS 1.9.7 (Mac OS X): Executed 2 of 2 SUCCESS (0.008 secs / 0.002 secs) |
junit报告会在当前目录下生成一个test-results.xml文件，文件中包含了可以用作其他工具的输入的junit xml。文件可以重命名为其他任意的名字。更多的信息请查看karma junit reporter文档。
使用testem生成测试覆盖率报告，目前需要更多的关注，尽管可以实现。更多的信息请查看testem文档。
使用karma来生成代码测试覆盖率需要安装另外一个node.js模块，通过下面的命令可以完成模块的安装。
1 |
npm install --save-dev karma-coverage |
安装完模块后，需要在karma的配置中添加下面的配置。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
module.exports = function(config) {
config.set({
/* snip */
reporters: ['progress', 'coverage'],
preprocessors: {
"your_ember_code_here.js": "coverage",
"your_test_code_here.js": "coverage"
},
coverageReporter: {
type: "text",
}
/* snip */
});
};
|
现在如同往常一样运行karma就能在终端中看到测试覆盖率信息的输出了。coverageReporter.type选项可以被设置为不同的值。示例中得值为text，将显示在控制台中。其他的值包括：lcov，html和cobertura，这些的输出可以用作其他工具的输入。karma更多关于测试覆盖率的配置项，可以查看karma文档。