先谈一下大背景
持续集成和持续发布
持续发布 Continuous Delivery, 是一整套围绕着如何在很短的周期里快速开发，频繁发布并确保产品质量的方法论，是为了拥抱敏捷Agile的原则而诞生：
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
持续集成 Continuous Integration，是一种让开发团队或个人的代码可以持续的合并进产品主线代码的策略， 可以认为这是一种版本管理的策略，每完成一个小功能就可以合并，通常是指每天的改动。
持续发布和持续集成给公司和团队带来好处是被大家认可的，是一种适应互联和云服务时代的产物。
那么笔者主要想介绍一下持续集成，持续发布中的重要环节:测试！
单元测试，集成测试，功能测试
这几种自动化测试是持续发布的基础，有了他们，可以大胆的每天，每小时都对产品进行改动和发布，大致尝试重构代码，小到完成一个简单的feature，而不用担心造成Regression issue, 听上去是不是可以说服老板采纳你那个被视为危险的改动了？
单元测试：确保单独的组件如预期的那样正常工作
集成测试：确保组件和组建之间的协作能正常的工作，断言点一般都是组建API, UI交互，数据库IO, 日志等
功能测试：确保整个应用基于用户的用例是正常工作的，断言点基本都在UI交互上。
以上几种测试都应该被使用，在开发环境中，工程师用TDD, BDD的方式同时编写单元测试和功能代码。在staging环境中，travis CI, Jenkins等持续集成工具自动运行集成测试和功能测试，判定新版本包含的改动是否能被发布。到了发布的生产环境，一部分重要的功能测试(烟雾测试Smoke test)用来判定发布是否成功。
此文主要是介绍一下Web前段世界里与UI交互有关的End-to-end测试，包括了集成测试和功能测试。
笔者认为，前端工程师是最适合实现功能测试代码的人选，因为我们每天就是在和UI交互打交道，最熟悉用户操作的用例细节。对于全栈Full stack工程师的定义也应该加上“能编写End-to-end测试代码“。
告诉你的老板，请不要再hire一支单独的自动化测试团队了:)
对于早期创业公司实现这三种测试，再大胆采用付费的Gitub和Travis CI等云服务，节省资金又事半功倍。
从Java Groovy 到 NodeJS
浏览器端自动化测试并不是一个新概念，所以已经有相当成熟的工具和理论, 简单介绍一下在Java世界相当出色的一款成熟的自动化工具库Geb。
接下来笔者参考它的一些被广泛认可的特性来比较NodeJS世界的替代框架。
Geb
Geb 本身并不是测试框架，而且是一个面向开发工程师的控制浏览器自动化交互的工具库。它接受Groovy脚本 作为基本的编写语言，利用了很多Groovy的语言特性来弥补Java灵活性不足，编写更加方便。
Geb的组成：
内核是Selenium WebDriver 老牌浏览器自动化工具
WebDriver是浏览器自动化界的老大哥，它支持市面上几乎所有种类的浏览器，从IE, Safari, Opera, Chrome, Firefox等桌面端浏览器到Android等移动平台上的浏览器, 而且是标准浏览器，而不是PhantomJS 所提供的非标准浏览器，顺便提一下，这就是为什么基于PhantomJS的测试框架一般只适合作 Javascript单元测试。
此外WebDriver还支持standalone的browser server, 就是被操控的浏览器和测试服务器可以是分离在 不同的机器上，进行远程控制，这样就可以linux上运行持续集成，但是测试的目标浏览器可以是装在 windows服务器上的IE。
WebDriver所提供的API能模拟控制浏览器的很多行为，诸如访问网址，调整窗体，按钮，上传文件，各种鼠标事件，甚至触控类操作。够获取浏览器的信息，比如页面元素的属性，内容，历史，Cookie，对网页截图等。
browser.drive {
go "http://myapp.com/login"
类jQuery selector的DOM元素选择器
assert $("h1").text() == "Please Login"
Page Object页面控制模型
Page Object本身是WebDriver提出的概念，对某类页面上的信息和针对该页面的用户行为操作的抽象封装。 简单的说，它使得Test Spec文件里不用直接编写对某个DOM元素的断言，而是抽象为对Page Object 自定义属性的断言，还可以起到被复用的作用，比如，你一定会想到定义一个Base Page Object. 并且Page Object的出现分离了页面的具体内容和测试用例的耦合，以后对UI的改动时都不太会影响到 Test Spec, 只需要修改相应的Page Object就可以了。
例如 Page Object：
class GebHomePage extends Page {
static url = "http://gebish.org"
static at = { title == "Geb - Very Groovy Browser Automation" }
static content = {
highlights { $("#sidebar .sidemenu").module(HighlightsModule) }
sectionTitles { $("#main h1")*.text() }
}
}
Test Spec文件：
def "can access The Book of Geb via homepage"() {
when:
to GebHomePage
and:
highlights.jQueryLikeApi.click()
then:
sectionTitles == ["Navigating Content", "Form Control Shortcuts"]
highlights.jQueryLikeApi.selected
}
大致来说Page Object的必要属性就是：
URL
有哪些必须出现的DOM元素，或者Title等
有哪些可能出现的DOM元素
有哪些用户发起的交互行为: 点击按钮，触碰滑动等
Section
Section是类似Page Object的次等概念，是对页面上一个局部可重用区域的抽象封装，对于定义复杂 的页面很有用，篇幅有限不多介绍了。
Spock
基于行为(Behavior)的测试断言库。
本身不属于Geb，但是通常被用于和Beb组合在一起作为一个完整的测试框架。
在NodeJS世界，我们有Jasmine, mocha + chai之类的更好的替代。
MockServer
对于集成测试，我们可能还需要对另一个部分，那就是服务器端Backend API的进行模拟，推荐相当强大的工具MockServer。
Mock server可以模拟HTTP or HTTPS的请求和响应，可以记录，代理请求和响应。
至此一般Web应用的End-to-end测试构架基本都是这样：
黄色部分就是End-to-end测试对象， 当然如果是功能测试可能就不需要使用MockServer了，因为测试对象覆盖整个前端与后台。
来看一下对应NodeJS世界继承者：
Selenium WebDriver
var webdriver = require('selenium-webdriver'),
By = require('selenium-webdriver').By,
until = require('selenium-webdriver').until;
var driver = new webdriver.Builder()
.forBrowser('firefox')
.build();
driver.get('http://www.google.com/ncr');
driver.findElement(By.name('q')).sendKeys('webdriver');
driver.findElement(By.name('btnG')).click();
driver.wait(until.titleIs('webdriver - Google Search'), 1000);
driver.quit();
Selenium WebDriver自家的Javascript端，所支持API和WebDriver其他语言的API基本保持一致， 大部分的API是异步调用，返回结果是Promise。 优点是运行速度快，支持CSS selector和XPath风格的元素选择API. 可以搭配Jasmine之类的测试框架，需要自己编写Page Object等model，但这并不难， 上面已经介绍了Geb中的Page Object pattern, 所以很简单, 而且灵活。
WebDriver.io
是一款基于WebDriver API协议的，远程调用WebDriver standalone服务器的浏览器自动化工具库，可以搭配 Mocha, Jasmine等测试框架. 优点是API是重新封装后的同步调用的，你可能会觉得编写Test Spec的 代码比原生Webdriver异步API的Promise代码更简洁。
有多种reporter插件等。 因为不是原生webDriver API, 而且需要单独启动WebDriver standalone服务器，运行速度比WebDriver自家的库慢，对于用例复杂的Web应用，持续集成的运行速度还是很重要的。
支持Page Object pattern, 对Jenkins, travis CI的集成比较友好，有完整的文档。
NightWatch.js
是另一款开箱即用的工具库，和Webdriver.io一样也重新封装了WebDriver API,也是通过远程访问 WebDriver standalone服务器, 有一套自己的定制版Mocha的测试断言库，不能搭配其他的测试断言库， 有一套自己的配置文件规范，灵活和可配性比较欠缺，而且重新封装后的API面临能否即使跟上WebDriver 原生API更新的步伐的问题，目前NightWatch声称API还在继续填补中。 支持Page Object pattern。
MockServer
MockServer 虽然是基于Java, 但是提供了NodeJS 的客户端，所以相当方便，支持转发端口, HTTP、HTTPS、Socket代理, 记录和重发请求，对于不参与后台API开发的前段团队来说，可以在开发期间，解耦对后台开发团队的依赖，当然更主要是我们可以用它来做集成测试时的模拟后台了。
MockServer的Node客户端，使用很简单：
mockServerClient("localhost", 1080).mockAnyResponse(
{
'httpRequest': {
'method': 'POST',
'path': '/somePath',
'queryStringParameters': [
{
'name': 'test',
'values': [ 'true' ]
}
],
'body': {
'type': "STRING",
'value': 'someBody'
}
},
'httpResponse': {
'statusCode': 200,
'body': JSON.stringify({ name: 'value' }),
'delay': {
'timeUnit': 'MILLISECONDS',
'value': 250
}
},
'times': {
'remainingTimes': 1,
'unlimited': false
}
}
);
使用MockServer 还需要启动一个服务器端，MockServer 提供了一个基于Grunt的插件，另外还有WAR包，Maven, Homebrew, Docker container形式的服务器端，因为毕竟是MockServer是Java编写的。
小结
笔者是一个年龄颇大的工程师，经历过早期百强公司依赖大量手工QA团队测试，通过烧录光碟发布产品的坎坷年代，也经历过任职在年轻的硅谷创业公司，没有一名QA工程师，却能做到隔天发布新feature，深深感受到做好持续集成、持续发布的好处。
由于篇幅有限，希望对持续集成里测试环节几款工具做了些简单介绍能给尚不熟悉的工程师们带个路，有机会再介绍持续集成中其他环节。
本文作者：刘晶（点融黑帮），一个玩web前端开发的code monkey，也喜欢UI 设计，他还做过后端开发，现担任点融前端资深开发工程师。
