做者:Philip Walton
译者:Yeaseon
原文连接:Learning How to Set Up Automated, Cross-browser JavaScript Unit Testingjavascript
译文仅供我的学习,不用于任何形式商业目的,转载请注明原做者、文章来源、翻译做者及连接,版权归原文做者全部。css
咱们都知道在多个浏览器中测试咱们的代码是多么的重要。至少在咱们发布第一个项目的时候,我认为咱们在网络开发社区作大部分工做仍是至关不错的。html
咱们作的不够好的工做是测试代码时每一次作出的改变。java
我我的对此感到很惭愧。我已经把“学习如何构建自动化、跨浏览器的JavaScript的单元测试”列在个人年度to-do清单中,但我每一次坐下来真正想要作的时候,我又退却了。虽然我确定这一部分缘由是由于个人懒惰,同时我认为这也是因为缺少良好的可用信息在这个主题上。node
有许多工具和框架(例如 Karma)宣称“要使自动化的JavaScript测试变得简单”,但以个人经验看来这些工具引入的复杂性比他们摆脱的复杂性更多。在个人工做经验中,若是你是一个专家这些工具“能工做”的很好,但对于一个初学者是很糟糕的。我想要真正了解的是这个流程是如何在引擎中工做的,以便在它出现问题的时候(总会出现问题的),我能解决它。webpack
对我来讲,充分了解这些是如何工做的最好方法就是尝试从头开始从新建立它。因此我决定去构建我本身的测试工具,而后把个人所学分享到社区中。git
在我解释自动化过程以前,我认为最重要的是确保咱们都在同一页面上进行手工测试工做。github
毕竟,自动化是关于使用机器来关闭负载的重复部分的现有工做流程。若是你在充分理解手工过程以前尝试去开始自动化,它也不会像你理解了自动化过程同样。web
在手工过程当中,你写了一个你的测试文件,它可能看起来像是:chrome
var assert = require('assert'); var SomeClass = require('../lib/some-class'); describe('SomeClass', function() { describe('someMethod', function() { it('accept thing A and transforms it into thing B',function() { var sc = new SomeClass(); assert.equal(sc.someMethod('A'), 'B'); }); }); });
这个例子用了Mocha和Node.js 资源模块,可是重要的不是你是用的测试库或者断言库,它可使任意一个。
在Mocha中运行Node.js,在你终端经过命令行你就能运行这个测试:
mocha test/some-class-test.js
你须要一个带有<script>
标签的HTML文件加载这段脚本,才能在浏览器运行这个测试,浏览器并不认识require
声明,你须要一个像是browserify或者webpack的模块打包工具去解决这些依赖。
browserify test/*-test.js > test/index.js
像是browserify或是webpack的模块打包工具的好处就是它能整合你的全部测试(也包括依赖)到一个单一的文件中,这样就能很容易加载到你的测试页面。
一个用Mocha写的典型测试文件看起来像是这样的:
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Tests<title> <link href="../node_modules/mocha/mocha.css" rel="stylesheet" /> <script src="../node_modules/mocha/mocha.js"></script> </head> <body> <!-- A container element for the visual Mocha results --> <div id="mocha"></div> <!-- Mocha setup and initiation code --> <script> mocha.setup('bdd'); window.onload = function() { mocha.run(); }; </script> <!-- The script under test --> <script src="index.js></script> </body> </html>
若是你不使用Node.js,那么你的起点看起来已经很像这个HTML文本了,惟一不一样的是你的依赖可能须要列成一个个单独的<script>
标签。
若是一个测试因为是断言不正确,你的断言库任什么时候间都会抛出一个错误,这个时候你的测试框架就能发现这个错误。测试框架运行在每一个测试的try/catch中来捕获可能会抛出的错误,这些错误报告会显示在你的页面中或是在console中显示这些log。
大多数的测试框架(像是Mocha)将会提供钩子,这样你就能在测试过程当中让页面中的其余脚本访问测试结果。这是一个自动化测试过程的一个关键特征,由于为了自动化工做,自动化脚本须要可以提取测试脚本的结果。
在浏览器中手工运行测试的最大好处是,假如你的一个测试失败了你能用浏览器的开发者工具去调试它。
像是这样的一个简单例子:
describe('SomeClass', () => { describe('someMethod', () => { it('accepts thing A and transforms it into thing B', () => { const sc = new SomeClass(); debugger: assert.equal(sc.someMethod('A'), 'B'); )}; )}; )};
如今当你从新打包并刷新浏览器打开开发者工具,你就能够经过你的代码,很容易定位到问题的根源所在。
相比之下,大多数流行的自动化测试框架使这变得很困难!它们提供的方便之处是它们捆绑了你的单元测试而且为你建立一个宿主的HTML页面。
在你的任何一个测试都不会失败的时候,这是很好的方式。由于当它们这样作时,就没有办法轻松地reproduce和本地调试。
手工流程有它的有点,同时也有一些缺点。打开几个浏览器去运行测试,每次你想作出改动的时候都会变得繁琐且容易出错。更不用说,咱们大部分人没有安装每个浏览器的每个版本到咱们的本地开发机器上。
若是你在认真的测试你的代码,并但愿确保它的每个变化都作适当的,那么你须要自动化这个流程。
不管你是多么的自觉,手动测试是太容易忘记或忽略,最终它不会充分利用你的时间。
可是自动化测试一样也有它的不足。过于频繁的自动测试工具引入了一个全新的问题。轻微不一样的构建,测试就会变得不一样,测试失败的话面临的将是痛苦的调试。
当我计划如何构建个人自动化测试系统的时候,我不想再掉进这个陷阱和失去手工测试流程的便利性。因此我决定在开始以前作一个需求列表。
毕竟,一个自动化系统若是引入了新的使人头疼的麻烦和复杂性,那它就不是一个成功的自动化系统。
我须要可以使用命令行运行测试
我须要可以在本地调试失败测试
我须要全部必需的依赖经过npm
运行测试就能被安装,因此任何人查看个人代码就能很简单的运行,经过
npm install && npm test
我须要运行在CI机器上的测试流程和运行在个人开发机器同样简单。这样构建方式是相同的,而且无需检查新的变化就能调试错误。
我须要全部的测试我(或者任意人)提交新的变化或者拉取请求都能在任什么时候间自动化运行。
有了这个粗略的列表以后,下一步就是深刻到在主流的云测试如何自动化,跨浏览器测试的工做。
有不少云测试的供应商,每一个供应商都有本身的长处和短处。我是一个开源做者,因此我只看那些提供开源项目的供应商,它们之中,只有Sauce Labs是惟一一个不须要我邮箱支持就能启动一个新的开源帐户。
更令我吃惊的是当我真正开始钻研Sauce Labs关于JavaScript单元测试的文档是有多么简单。因为好多测试框架都有声称让单元测试变得简单,我认为这真的很难!
我前面强调了一点就是,我不想个人自动化流程和个人手工流程有什么根本上的不一样。事实证实,Sauce Labs提供的自动化方法真的很像个人手工方法。
这里是所涉及的步骤:
你给Sauce Labs一个你测试页面的URL以及你要运行的测试的浏览器/平台列表。
Sauce Labs使用selenium webdriver去加载你给它的每个浏览器和平台的组合的测试页面。
WebDriver检查网页是否测试失败,并将结果存储。
Sauce Labs将有用的结果给你。
这真的很简单。
我错误地假设你不得不把你的JavaScript代码给Sauce Labs,而且它将会运行在它的机器上,而不是它们只是去访问你给它们的URL。这样的话看起来就像手工流程了;惟一不一样的是Sauce Labs去打开全部的浏览器并为你记录下结果。
Sauce Labs有两个运行单元测试的API方法:
StartJS Unit Tests方法在你指定的浏览器/平台启动一个测试页面。
文档给了一个使用curl
的例子:
curl https://saucelabs.com/rest/v1/SAUCE_USERNAME/js-tests \ -X POST \ -u SAUCE_USERNAME:SAUCE_ACCESS_KEY \ -H 'Content-Type: application/json' \ --data '{"url": "https://example.com/tests.html", "framework": "mocha", "platforms": [["Windows 7", "firefox", "27"], ["Linux", "chrome", "latest"]]}'
由于这是JavaScript单元测试,我将给你一个使用node模块request的例子,若是你正在用Node.js它可能更接近你最终要作的:
request({ url: `https://saucelabs.com/rest/v1/${username}/js-tests`, method: 'POST', auth: { username: process.env.SAUCE_USERNAME, password: process.env.SAUCE_ACCESS_KEY }, json: true, body: { url: 'https://example.com/tests.html', framework: 'mocha', platforms: [ ['Windows 7', 'firefox', '27'], ['Linux', 'chrome', 'latest'] ] } }, (err, response) => { if (err) { console.error(err); } else { console.log(response.body); } });
你注意到body中的framework: 'mocha'
。Sauce Labs供应商支持许多主流的JavaScript单元测试框架,包括 Mocha,Jasmine,Qunit和YUI。“支持”意味着Sauce Labs的webdriver客户端知道去哪获取测试结果。
若是你没有使用上面提到的测试框架,你能能够经过设置framework: 'custom'
,Sauce Labs将会代替找到的全局变量window.global_test_results
。格式化的结果被列在文档中的自定义框架一节中。
让Mocha测试结果对于Sauce Labs的webdriver客户端有用
尽管你在最初的请求中告诉Sauce Labs你在使用Mocha,你仍然须要去更新你的HTML页面,去存储Sauce Labs能访问的全局变量的测试结果。
为你的HTML页面增长Mocha支持:
<script> mocha.setup('bdd'); window.onload = function() { mocha.run(); }; </script>
作一些事情,像下面这样:
<script> mocha.setup('bdd'); window.onload = function() { var runner = mocha.run(); var failedTests = []; runner.on('end', function() { window.mochaResults = runner.stats; window.mochaResults.reports = failedTests; }); runner.on('fail', logFailure); function logFailure(test, err){ var flattenTitles = function(test){ var titles = []; while (test.parent.title){ titles.push(test.parent.title); test = test.parent; } return titles.reverse(); }; failedTests.push({ name: test.title, result: false, message: err.message, stack: err.stack, titles: flattenTitles(test) }); }; }; </script>
在上面的代码和默认的Mocha模板中惟一不一样的是分配给测试结果的变量名,就像Sauce Labs指望的格式同样叫作window.mochaResults
。由于这个新的代码不会影响正在浏览器中运行的手工测试,你不妨就开始使用它做为默认的Mocha模板。
再次强调一点,当Sauce Labs“运行”你的测试时,它并无作任何事,它只是单纯的访问一个页面,等到发现一个window.mochaResults
对象,而后记录下这个结果。
肯定你的测试经过仍是失败
StartJS Unit Tests 方法会告诉Sauce Labs去挨个在你指定的浏览器/平台运行测试,可是它不会返回测试的结果。
它返回全部工做队列中的ID,响应看起来像是这样的:
{ "js tests": [ "9b6a2d7e6c8d4fd2afeeb0ff7e54e694", "d38688ec7256497da6966f4523ddee76", "14054e68ccd344c0bed77a798a9ce1e8", "dbc54181f7d947458f52201ea5fcb901" ] }
要肯定你测试经过仍是失败,你要调用GetJS Unit Status方法,它接手一个工做队列而且返回当前每一个工做的工做状态。
这个想法是你要按期调用这个方法,知道全部工做都完成。
request({ url: `https://saucelabs.com/rest/v1/${username}/js-tests/status`, method: 'POST', auth: { username: process.env.SAUCE_USERNAME, password: process.env.SAUCE_ACCESS_KEY }, json: true, body: jsTests, // The response.body from the first API call. }, (err, response) => { if (err) { console.error(err); } else { console.log(response.body); } });
响应的结果看起来像是这样:
{ "completed": false, "js tests": [ { "url": "https://saucelabs.com/jobs/75ac4cadb85e415fae957f7811d778b8", "platform": [ "Windows 10", "chrome", "latest" ], "result": { "passes": 29, "tests": 30, "end": {}, "suites": 7, "reports": [], "start": {}, "duration": 97, "failures": 0, "pending": 1 }, "id": "1f74a237d5ba4a47b5a42570ae1e7999", "job_id": "75ac4cadb85e415fae957f7811d778b8" }, // ... the rest of the jobs ] }
一旦response.body.complete
属性值为true
,就表示你的测试已经运行完成,而后你就能够经过检查每一个工做流程的经过仍是失败。
我已经解释过Sauce Labs“运行”你的测试经过访问一个URL。固然,这意味着这个URL必须是公开在网络上可访问的连接。
有一个问题就是若是你的测试服务启动在localhost
。
有不少解决这个问题的方案,包括Sauce Connect(官方推荐的一种),这是一个由Sauce Labs建立的代理服务器,在Sauce Labs虚拟机和本地主机之间开启一个安全链接。
Sauce Labs是处于安全性的考虑被设计的,而且使得外部没法得到你的代码。它的缺点就是十分复杂的设置与使用。
若是你的代码涉及到安全性,它可能值得你去弄清楚Sauce Labs;若是不是的话,有许多类似的方案去更简单的解决这个问题。
我选择的方案是ngrok
ngrok
ngrok是一个用于建立安全隧道链接工具。它给你一个公共的URL到web服务器运行在你的本地机器上,确切的是你须要运行测试在Sauce Labs上。
若是你在虚拟机上进行开发或手动测试,你可能已经据说过ngrok,若是没有,那你应该去查阅一下了,它是极其有用的工具。
在你的机器上安装ngrok像是下载二进制文件,而后添加到你的路径中同样简单;若是你将会在Node中使用ngrok,你也须要经过npm安装它。
npm install ngrok
你能够用下面的代码以编程方式从Node中开始ngrok进程:
const ngrok = require('ngrok'); ngrok.connect(port, (err, url) => { if (err) { console.error(err); } else { console.log(`Tests now accessible at: ${url}`); } });
只要你有一个公共的URL能访问你的测试文件,用Sauce Labs跨浏览器测试你的本地代码会变得十分容易。
这篇文章包含了不少主题,给人的印象是自动化的,跨浏览器的JavaScript单元测试是复杂的。但状况并不是如此。
我从个人角度来看这篇文章-当我试图去解决这个问题。而后回顾我以前的经验,真正复杂的是缺乏解决整个流程如何工做的有效信息,和怎么样把全部的整合到一块儿。
一旦你了解了全部的步骤,它很简单。总结:
最初的手工流程
写一个测试而后建立一个单一的HTML页面去运行它。
在本地的一个或者两个浏览器中运行这个测试,确保它能工做。
增长自动化流程
建立一个开源的Sauce Labs帐号,得到一个用户名和访问权限。
更新你的测试页面源码,以便Sauce Labs能经过JavaScript全局变量读取测试结果。
用ngrok给你的本地测试页面建立一个安全隧道,这样就能在互联网公开的访问了。
调用StartJS Unit Tests接口方法列出你想测试的浏览器/平台。
定时调用GetJS Unit Test Status方法知道工做完成。
报告结果。
我知道这篇文章开头我谈了不少关于你不须要一个框架来作自动化,跨浏览器的JavaScript单元测试,我如今仍然坚信这个。然而,尽管每一步都很简单,你可能不想在每次都为项目编写代码。
我想给个人不少老项目增长自动化测试,因此对我来讲打包这些逻辑到个人模块中是颇有意义的。
我推荐你尝试实现一个你本身的框架,这样你就能够彻底理解它是如何工做的,但若是你没有时间而且还想快速创建一个测试,我建议你使用我建立的库Easy Sauce。
Easy Sauce是一个Node包和一个命令行工具,如今我为我想作跨浏览器测试的每个JavaScript项目都使用这个包。
easy-sauce
命令能够设置你的HTML测试文件的路径(默认是/test/
)、开启本地服务的端口(默认是1337
端口)和一系列的浏览器/平台进行测试。easy-sauce
将会在Sauce Lab’s selenium cloud运行你的测试,将日志打印在控制台并经过合适的状态码告知你测试是否经过。
npm包使它变得更方便,easy-sauce
将会默认在package.json
文件中查找配置选项,因此你没必要分别的存储它们。好处是用户更加明确的知道你的包支持浏览器/平台。
对于easy sauce
完整的用法介绍,请查看Github文档。
最后,我想强调的是我专门创建这个项目来解决个人须要。虽然我认为这个项目对于不少开发人员都十分有用,但我没有计划把它变成一个功能齐全的测试解决方案。
在这篇文章的开始,我写下了一系列的需求。在Easy Sauce的帮助下,我正努力的在任何项目中知足这些需求。
若是你尚未为你的项目作自动化、跨浏览器的JavaScript单元测试,我鼓励你给Easy Sauce一个尝试的机会。即便你不想用Easy Sauce,你至少应该了解你本身的需求或更好地了解现有的工具。
Happy testing!
若是你能看到这里,很感谢你的耐心阅读。这是我翻译的第一篇技术文档,自身水平有限,因此翻译总有不当与疏漏,若有发现还请您耐心评论指出。