Test driven-frontend-develop
1 like428 views
该文档探讨了前端开发中的挑战与解决方案，强调自动化测试和测试驱动开发（TDD）在提高开发效率和代码质量方面的重要性。内容包括前端开发的复杂性、自动化工具的使用，以及如何通过持续集成来支持测试过程。作者鼓励更多人参与TDD实践，以提升前端开发的整体质量和效率。
Test driven-frontend-develop
- 2. About me... ● Flash Actionscript Developer ● 写一点点 JS ● Ruby 粉丝 ● 最爱 web applications ● 研究 / 开发各种工具 ● 目前在架构组，负责前端开 发的工具支持
- 3. 曾经 ... ● 前端是一片未开垦的 自由大陆 ● 我们是第一代前端开 发工程师
- 4. 我们无所畏惧 ● 并引以为豪 ● 就像他们
- 5. Orville Wright & Wilbur Wright 1903
- 6. 时间推移 ● 客户端的功能越来越 强 ● Web 体验越来越好
- 7. 同时，我们还关注 ... ● 减少带宽流量 ● 提升 Web 性 ● 如何在各种设备上 有一致的良好体验 ● 减轻服务器压力 能，进而提升 减少跨设备的迁移 懒加载，仅加载当 客户转化率 ● ● 前最需要的数据 成本 MONEY
- 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. 如何写出好的测试
- 41. 可读性 ● BDD 风格 ● 一个 test 方法只测试一个内容 ● 不断重构，优化
- 42. 测试脚本也是程序 ● 发现程序的 bug ，就 加入到测试脚本中
- 43. 维护的烦恼 ● 改了 A 页面功能却造 成了 B 页面的故障 ● 开发充满危机感，不 敢删代码、删文件… …放心重构 ● 维护成为沉重的负担
- 44. 持续集成
- 45. End ● 不是为了分享，而是为了寻找支持 ● 前端 TDD 需要大家的努力 ● 前端质量 & 效率提升需要大家贡献 ● 希望有更多的人参与 TDD 实践，总结出更好的 经验 ● 不管其他人怎么评价 TDD ，去尝试一下
- 46. Thank you all!
- 47. Any questions?