Test driven-frontend-develop

1,095 views

Published on

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,095
On SlideShare
0
From Embeds
0
Number of Embeds
230
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Test driven-frontend-develop

  1. 1. 测试驱动的前端开发 & 前端自动化测试实践
  2. 2. About me... ● Flash Actionscript Developer ● 写一点点 JS ● Ruby 粉丝 ● 最爱 web applications ● 研究 / 开发各种工具 ● 目前在架构组,负责前端开 发的工具支持
  3. 3. 曾经 ... ● 前端是一片未开垦的 自由大陆 ● 我们是第一代前端开 发工程师
  4. 4. 我们无所畏惧● 并引以为豪● 就像他们
  5. 5. Orville Wright & Wilbur Wright 1903
  6. 6. 时间推移 ● 客户端的功能越来越 强 ● Web 体验越来越好
  7. 7. 同时,我们还关注 ...● 减少带宽流量 ● 提升 Web 性 ● 如何在各种设备上 有一致的良好体验● 减轻服务器压力 能,进而提升 减少跨设备的迁移 懒加载,仅加载当 客户转化率 ●● 前最需要的数据 成本 MONEY
  8. 8. Now happening
  9. 9. 我们在这里 ● ?
  10. 10. 挑战 ● 开发的复杂度增加 ● 设备兼容难度增加 ● 质量要求更高了 ● 效率要求更高了
  11. 11. 我们准备好了吗?
  12. 12. Part II.前端开发之痛
  13. 13. 同一个功能要在多种浏 改了 A 页面功能却造成了● 览器中测试 ● 文档总是没法 ● B 页面的故障● 同样的流程要手工进行 及时随代码更 ● 开发充满危机感,不敢放 心重构 很多次 新 ● 维护成为沉重的负担● 浏览器版本更新,不断 有新的浏览器加入 ● 被咬了才知道
  14. 14. 测试的烦恼 ● 同一个功能要在多种 浏览器中测试 ● 同样的流程要手工进 行很多次 ● 浏览器版本更新,不 断有新的浏览器加入
  15. 15. 解决方案思考● 增加测试资源投入 ● 自动化 UI 测试 ● 简单有效 ● 成本更低 ● 不能面面俱到 ● 便于维护 ● 测试有难度 ● 工具不成熟
  16. 16. 从手工测试到自动化测试
  17. 17. Level 1● 操作,肉眼检查结果是否正确
  18. 18. Level 2● 操作,用 alert/console.log/$.log 检查输出结果
  19. 19. Level 3● 将操作编写为脚本, 模拟手工操作或模拟 操作的结果● Console.log● 手工打开浏览器
  20. 20. Level 4● 操作脚本 + 测试框架● 手工打开浏览器
  21. 21. Level 5● 用脚本模拟操作● 脚本自动打开浏览器● 脚本自动处理测试结 果
  22. 22. Zombie.js 实践
  23. 23. Zombie.js● Headless: 快速、无需真实浏览器● 基于 node.js● 模拟浏览器● 命令行方式运行
  24. 24. 安装● 安装 node.js● 安装 zombie.js ● npm install zombie
  25. 25. example
  26. 26. 遇到的问题● 适合 zombie.js 的测试框架 ● Jasmine / vows ?● 与真实浏览器有差异 ● Global scope ● Document.write● Ajax 数据模拟 ● Nock● 中文问题 ● Iconv
  27. 27. 难点● 大部分代码难以用 on page js 测试 ● 动画 ● 用户操作,如选择文件 ● 布局兼容性● 对策 ● 使用 MVC ,测试 Model 和 Control ● 用 js 测试“状态相关”的功能(单元测试) ● 用 ruby/selenium 测试“操作相关”的功能
  28. 28. 难点● Ajax 操作、 setTimeout 等异步功能● 对策 ● 主流的测试框架都已支持异步测试
  29. 29. 难点● 不同类型用户的构造 ● 诚信通用户 ● 炫旺铺用户 ● 手机认证用户 ● 支付宝实名认证用户 ● ……● 对策 ● 数据银行 ● 尝试用程序在 HTML 结构上反映用户类型
  30. 30. JSTestDriver
  31. 31. example
  32. 32. JSTestDriver● 建立一个服务器● 支持任意种类、数量的浏览器● 命令行运行● 并行测试,效率高● 可以很方便与持续集成 (CI) 系统集成● 有 IDE 插件● 提供代码覆盖率数据● 专注于 js 的测试,对 HTML 支持不好● 适合单元测试,不适合功能测试
  33. 33. 隐藏的危险 ● 文档总是没法及时随 代码更新 ● 被咬了才知道
  34. 34. 测试是很好,可是……● “ 写测试太花时间,项目时间太紧”● “ 功能很难测试”
  35. 35. 这是因为 没有测试驱动开发
  36. 36. TDD 的流程● 编写测试 ● 让测试编译通过,但 是测试失败● 重构代码 ● 让测试通过
  37. 37. 先写测试带来的好处● 迫使我们先思考 ● 哪些模块可以被测试 ● 怎么样分模块可以更容易维护功能和测试 – SRP ● 单一模块怎样设计可以方便测试 – 暴露 ajax 回调方法 – 完全分隔 MVC● 不断前进,成就感● 有测试保证质量,写的过程中可以随时重构
  38. 38. TDD 陷阱● “ 错误的文档还不如没有文档”● 不干净的测试脚本反而会增加维护成本
  39. 39. 如何写出好的测试
  40. 40. mocking & stubbing
  41. 41. 可读性● BDD 风格● 一个 test 方法只测试一个内容● 不断重构,优化
  42. 42. 测试脚本也是程序● 发现程序的 bug ,就 加入到测试脚本中
  43. 43. 维护的烦恼 ● 改了 A 页面功能却造 成了 B 页面的故障 ● 开发充满危机感,不 敢删代码、删文件… …放心重构 ● 维护成为沉重的负担
  44. 44. 持续集成
  45. 45. End● 不是为了分享,而是为了寻找支持● 前端 TDD 需要大家的努力● 前端质量 & 效率提升需要大家贡献● 希望有更多的人参与 TDD 实践,总结出更好的 经验● 不管其他人怎么评价 TDD ,去尝试一下
  46. 46. Thank you all!
  47. 47. Any questions?

×