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

2. About me...
● Flash Actionscript
Developer
● 写一点点 JS
● Ruby 粉丝
● 最爱 web applications
● 研究 / 开发各种工具
● 目前在架构组，负责前端开
发的工具支持

3. 曾经 ...
● 前端是一片未开垦的
自由大陆
● 我们是第一代前端开
发工程师

4. 我们无所畏惧
● 并引以为豪
● 就像他们

5. Orville Wright & Wilbur Wright
1903

6. 时间推移
● 客户端的功能越来越
强
● Web 体验越来越好

7. 同时，我们还关注 ...
● 减少带宽流量 ● 提升 Web 性 ● 如何在各种设备上
有一致的良好体验
● 减轻服务器压力 能，进而提升
减少跨设备的迁移
懒加载，仅加载当 客户转化率
●
●
前最需要的数据 成本
MONEY

8. Now happening

9. 我们在这里 ● ？

10. 挑战
● 开发的复杂度增加
● 设备兼容难度增加
● 质量要求更高了
● 效率要求更高了

11. 我们准备好了吗？

12. Part II.
前端开发之痛

13. 同一个功能要在多种浏 改了 A 页面功能却造成了
●
览器中测试
● 文档总是没法 ●
B 页面的故障
● 同样的流程要手工进行 及时随代码更 ● 开发充满危机感，不敢放
心重构
很多次 新 ● 维护成为沉重的负担
● 浏览器版本更新，不断
有新的浏览器加入 ● 被咬了才知道

14. 测试的烦恼
● 同一个功能要在多种
浏览器中测试
● 同样的流程要手工进
行很多次
● 浏览器版本更新，不
断有新的浏览器加入

15. 解决方案思考
● 增加测试资源投入 ● 自动化 UI 测试
● 简单有效 ● 成本更低
● 不能面面俱到 ● 便于维护
● 测试有难度
● 工具不成熟

16. 从手工测试到自动化测试

17. Level 1
● 操作，肉眼检查结果是否正确

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

19. Level 3
● 将操作编写为脚本，
模拟手工操作或模拟
操作的结果
● Console.log
● 手工打开浏览器

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

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

22. Zombie.js 实践

23. Zombie.js
● Headless: 快速、无需真实浏览器
● 基于 node.js
● 模拟浏览器
● 命令行方式运行

24. 安装
● 安装 node.js
● 安装 zombie.js
● npm install zombie

25. example

26. 遇到的问题
● 适合 zombie.js 的测试框架
● Jasmine / vows ?
● 与真实浏览器有差异
● Global scope
● Document.write
● Ajax 数据模拟
● Nock
● 中文问题
● Iconv

27. 难点
● 大部分代码难以用 on page js 测试
● 动画
● 用户操作，如选择文件
● 布局兼容性
● 对策
● 使用 MVC ，测试 Model 和 Control
● 用 js 测试“状态相关”的功能（单元测试）
● 用 ruby/selenium 测试“操作相关”的功能

28. 难点
● Ajax 操作、 setTimeout 等异步功能
● 对策
● 主流的测试框架都已支持异步测试

29. 难点
● 不同类型用户的构造
● 诚信通用户
● 炫旺铺用户
● 手机认证用户
● 支付宝实名认证用户
● ……
● 对策
● 数据银行
● 尝试用程序在 HTML 结构上反映用户类型

30. JSTestDriver

31. example

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

33. 隐藏的危险
● 文档总是没法及时随
代码更新
● 被咬了才知道

34. 测试是很好，可是……
● “ 写测试太花时间，项目时间太紧”
● “ 功能很难测试”

35. 这是因为
没有
测试
驱动
开发

36. TDD 的流程
● 编写测试 ● 让测试编译通过，但
是测试失败
● 重构代码 ● 让测试通过

37. 先写测试带来的好处
● 迫使我们先思考
● 哪些模块可以被测试
● 怎么样分模块可以更容易维护功能和测试
– SRP
● 单一模块怎样设计可以方便测试
– 暴露 ajax 回调方法
– 完全分隔 MVC
● 不断前进，成就感
● 有测试保证质量，写的过程中可以随时重构

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

39. 如何写出好的测试

40. mocking & stubbing

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

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

43. 维护的烦恼
● 改了 A 页面功能却造
成了 B 页面的故障
● 开发充满危机感，不
敢删代码、删文件…
…放心重构
● 维护成为沉重的负担

44. 持续集成

45. End
● 不是为了分享，而是为了寻找支持
● 前端 TDD 需要大家的努力
● 前端质量 & 效率提升需要大家贡献
● 希望有更多的人参与 TDD 实践，总结出更好的
经验
● 不管其他人怎么评价 TDD ，去尝试一下

46. Thank you all!

47. Any questions?