测试驱动的前端开发& 前端自动化测试实践

About me...

● Flash Actionscript Developer

● 写一点点 JS

● Ruby 粉丝

● 最爱 web applications

● 研究 / 开发各种工具

● 目前在架构组，负责前端开发的工具支持

曾经 ...

● 前端是一片未开垦的自由大陆

● 我们是第一代前端开发工程师

我们无所畏惧

● 并引以为豪● 就像他们

Orville Wright & Wilbur Wright 1903

时间推移

● 客户端的功能越来越强

● Web 体验越来越好

同时，我们还关注 ...

● 如何在各种设备上有一致的良好体验

● 减少跨设备的迁移成本

● 提升 Web 性能，进而提升客户转化率

● 减少带宽流量

● 减轻服务器压力

● 懒加载，仅加载当前最需要的数据

MONEY

Now happening

● ？我们在这里

挑战

● 开发的复杂度增加● 设备兼容难度增加

● 质量要求更高了● 效率要求更高了

我们准备好了吗？

Part II. 前端开发之痛

● 改了 A页面功能却造成了B页面的故障

● 开发充满危机感，不敢放心重构

● 维护成为沉重的负担

● 文档总是没法及时随代码更新

● 被咬了才知道

● 同一个功能要在多种浏览器中测试

● 同样的流程要手工进行很多次

● 浏览器版本更新，不断有新的浏览器加入

测试的烦恼

● 同一个功能要在多种浏览器中测试

● 同样的流程要手工进行很多次

● 浏览器版本更新，不断有新的浏览器加入

解决方案思考

● 增加测试资源投入● 简单有效● 不能面面俱到

● 自动化 UI 测试● 成本更低● 便于维护● 测试有难度● 工具不成熟

从手工测试到自动化测试

Level 1

● 操作，肉眼检查结果是否正确

Level 2

● 操作，用alert/console.log/$.log 检查输出结果

Level 3

● 将操作编写为脚本，模拟手工操作或模拟操作的结果

● Console.log● 手工打开浏览器

Level 4

● 操作脚本 + 测试框架● 手工打开浏览器

Level 5

● 用脚本模拟操作● 脚本自动打开浏览器● 脚本自动处理测试结

果

Zombie.js 实践

Zombie.js

● Headless: 快速、无需真实浏览器● 基于 node.js

● 模拟浏览器● 命令行方式运行

安装

● 安装 node.js

● 安装 zombie.js● npm install zombie

example

遇到的问题

● 适合 zombie.js 的测试框架● Jasmine / vows ?

● 与真实浏览器有差异● Global scope● Document.write

● Ajax 数据模拟● Nock

● 中文问题● Iconv

难点

● 大部分代码难以用 on page js 测试● 动画● 用户操作，如选择文件● 布局兼容性

● 对策● 使用 MVC ，测试 Model和 Control● 用 js 测试“状态相关”的功能（单元测试）● 用 ruby/selenium 测试“操作相关”的功能

难点

● Ajax 操作、 setTimeout等异步功能● 对策

● 主流的测试框架都已支持异步测试

难点

● 不同类型用户的构造● 诚信通用户● 炫旺铺用户● 手机认证用户● 支付宝实名认证用户● ……

● 对策● 数据银行● 尝试用程序在 HTML 结构上反映用户类型

JSTestDriver

example

JSTestDriver

● 建立一个服务器● 支持任意种类、数量的浏览器● 命令行运行● 并行测试，效率高● 可以很方便与持续集成 (CI)系统集成● 有 IDE插件● 提供代码覆盖率数据● 专注于 js 的测试，对HTML 支持不好● 适合单元测试，不适合功能测试

隐藏的危险

● 文档总是没法及时随代码更新

● 被咬了才知道

测试是很好，可是……

● “写测试太花时间，项目时间太紧”● “功能很难测试”

这是因为

没有

测试驱动开发

TDD 的流程

● 编写测试 ● 让测试编译通过，但是测试失败

● 让测试通过● 重构代码

先写测试带来的好处

● 迫使我们先思考● 哪些模块可以被测试● 怎么样分模块可以更容易维护功能和测试

– SRP

● 单一模块怎样设计可以方便测试– 暴露 ajax回调方法– 完全分隔MVC

● 不断前进，成就感● 有测试保证质量，写的过程中可以随时重构

TDD陷阱

● “错误的文档还不如没有文档”● 不干净的测试脚本反而会增加维护成本

如何写出好的测试

mocking & stubbing

可读性

● BDD风格● 一个 test 方法只测试一个内容● 不断重构，优化

测试脚本也是程序

● 发现程序的 bug ，就加入到测试脚本中

维护的烦恼

● 改了 A 页面功能却造成了 B 页面的故障

● 开发充满危机感，不敢删代码、删文件……放心重构

● 维护成为沉重的负担

持续集成

End

● 不是为了分享，而是为了寻找支持● 前端 TDD 需要大家的努力● 前端质量 & 效率提升需要大家贡献● 希望有更多的人参与 TDD 实践，总结出更好的

经验● 不管其他人怎么评价 TDD ，去尝试一下

Thank you all!

Any questions?