先谈一下大背景
持续集成和持续发布
持续发布ContinuousDelivery,是一整套围绕着如何在很短的周期里快速开发，频繁发布并确保产品质量的方法论，是为了拥抱敏捷Agile的原则而诞生：
Ourhighestpriorityistosatisfythecustomerthroughearlyandcontinuousdeliveryofvaluablesoftware.
持续集成ContinuousIntegration，是一种让开发团队或个人的代码可以持续的合并进产品主线代码的策略，可以认为这是一种版本管理的策略，每完成一个小功能就可以合并，通常是指每天的改动。
持续发布和持续集成给公司和团队带来好处是被大家认可的，是一种适应互联和云服务时代的产物。
那么笔者主要想介绍一下持续集成，持续发布中的重要环节:测试！
单元测试，集成测试，功能测试这几种自动化测试是持续发布的基础，有了他们，可以大胆的每天，每小时都对产品进行改动和发布，大致尝试重构代码，小到完成一个简单的feature，而不用担心造成Regressionissue,听上去是不是可以说服老板采纳你那个被视为危险的改动了？
单元测试：确保单独的组件如预期的那样正常工作
集成测试：确保组件和组建之间的协作能正常的工作，断言点一般都是组建API,UI交互，数据库IO,日志等
功能测试：确保整个应用基于用户的用例是正常工作的，断言点基本都在UI交互上。
以上几种测试都应该被使用，在开发环境中，工程师用TDD,BDD的方式同时编写单元测试和功能代码。在staging环境中，travisCI,Jenkins等持续集成工具自动运行集成测试和功能测试，判定新版本包含的改动是否能被发布。到了发布的生产环境，一部分重要的功能测试(烟雾测试Smoketest)用来判定发布是否成功。
此文主要是介绍一下Web前段世界里与UI交互有关的End-to-end测试，包括了集成测试和功能测试。
笔者认为，前端工程师是最适合实现功能测试代码的人选，因为我们每天就是在和UI交互打交道，最熟悉用户操作的用例细节。对于全栈Fullstack工程师的定义也应该加上“能编写End-to-end测试代码“。
告诉你的老板，请不要再hire一支单独的自动化测试团队了:)
对于早期创业公司实现这三种测试，再大胆采用付费的Gitub和TravisCI等云服务，节省资金又事半功倍。
从JavaGroovy到NodeJS浏览器端自动化测试并不是一个新概念，所以已经有相当成熟的工具和理论,简单介绍一下在Java世界相当出色的一款成熟的自动化工具库Geb。
接下来笔者参考它的一些被广泛认可的特性来比较NodeJS世界的替代框架。
GebGeb本身并不是测试框架，而且是一个面向开发工程师的控制浏览器自动化交互的工具库。它接受Groovy脚本作为基本的编写语言，利用了很多Groovy的语言特性来弥补Java灵活性不足，编写更加方便。
Geb的组成：
内核是SeleniumWebDriver老牌浏览器自动化工具
WebDriver是浏览器自动化界的老大哥，它支持市面上几乎所有种类的浏览器，从IE,Safari,Opera,Chrome,Firefox等桌面端浏览器到Android等移动平台上的浏览器,而且是标准浏览器，而不是PhantomJS所提供的非标准浏览器，顺便提一下，这就是为什么基于PhantomJS的测试框架一般只适合作Javascript单元测试。
此外WebDriver还支持standalone的browserserver,就是被操控的浏览器和测试服务器可以是分离在不同的机器上，进行远程控制，这样就可以linux上运行持续集成，但是测试的目标浏览器可以是装在windows服务器上的IE。
WebDriver所提供的API能模拟控制浏览器的很多行为，诸如访问网址，调整窗体，按钮，上传文件，各种鼠标事件，甚至触控类操作。够获取浏览器的信息，比如页面元素的属性，内容，历史，Cookie，对网页截图等。
browser.drive{