1. 前端单元测试

2. 大纲
・单元测试的概念
・为什么要做单元测试
・TDD BDD
・前端单元测试工具
・前端单元测试实战
・留在最后的问题

3. 概念
单元测试
断⾔言
用于表达程序设计人员对于系统应达到状态的一种预期，
是单元测试的核心部分
对软件中最小可测试单元进行检查和验证
它把对象设置成已知状态，然后运行他们检测出结果，
并将其与所预测的结果相对照

5. 实例

6. 为什么要单元测试

7. 前端的现状
• javascript语言本身没有提供好的架构模式
• 动态语言的灵活性，导致代码形式多样
• 面向用户，需求灵活多变，需要快速上线
• 很少重构，看不到收益，代码质量没有保障
• 各种浏览器、各种终端让⼈人头疼
• 还有很多头疼的问题

9. 单元测试能够带来什么

10. 能够给予及时反馈
对代码修改或者单元测试出问题后，能够
第一时间发现问题，而不是在线上发现

11. 代码质量
・代码质量如何度量
・如果没有测试如何来保证代码质量

12. 回归测试
・以前解决了一个BUG，后来又出现了
・发布新版本时，所有功能都要人工测试

13. 重构
・在没有单元测试的情况下，怎么做重构
・有可靠的度量来说明重构是否成功么
给你要改变的代码建立一组坚实的测试
-- Martin Fowler

14. 极大减少调试时间
单元测试要求代码解耦，针对每个行为单
元写用例，所以测试失败更容易找到问题
所在位置

15. 促进更好的设计
・单元测试要求代码松耦合
・单元测试要求代码接口简单、职责单一
・单元测试要求函数行为明确

16. ⽤用例即⽂文档
通过⽤用例可以让代码使⽤用者更容易的理解
代码

17. 增强自信心

19. Test-Driven
Development

20. 概念
• 敏捷中常⽤用的⽅方法
• 提倡⽤用测试来驱动应⽤用程序的创建
• 期望短时间内对软件进⾏行渐进式设计

21. TDD流程

22. ・测试驱动实现，促使每一行代码都可测
・测试作为实现的正确导向，让开发过程
更高效
・让应用程序长期处于稳定
TDD的愿景
TDD的问题
对设计和测试的编写没有明确的约束

23. Behavior-Driven
Development

24. ・TDD是方法，BDD是规约
・针对行为描述的测试，更具体，更直观
・直白的描述更容易让相关人员介入测试
行为驱动开发，TDD的子集
当⽤用户注册时，应⽤用程序应当接受POST请求，检查
字段是否有效，然后将数据库中的⽤用户数递增1
作为⼀一个⽤用户，当我成功注册时，我应该看到“感
谢注册”

26. !
• TDD能够保证总是先有测试再有代码且
不断迭代
• BDD能够正确的对系统的行为进行设计
• 两者是互补的

27. 前端测试工具

28. 眼花缭乱的测试框架

29. Jasmine Mocha Qunit
should chai expect
sinon blanket
jscoverage Vows
JsUnit YUITest JsSpec

31. 组装测试套件
• ⼀一套⽀支持BDD⻛风格的测试框架
• ⼀一套灵活全⾯面，符合习惯的断⾔言库
• ⼀一套代码覆盖率的框架
• 能够⽅方便Stub, Spies, Mock数据的框架

32. Mocha很不错

33. • 同时⽀支持浏览器和Node
• 设计灵活，可以选⽤用TDD和BDD的⻛风格
• 可以选⽤用不同⻛风格的断⾔言库
• 很好的⽀支持异步测试
• 详细的⽂文档
• 稳定的社区
• 当然还有明星的作者TJ...

36. Sinon的能⼒力
• Spies
• Stubs
• Mocks
• Fack times
• Fack XHR and server

37. 实战演示

38. 留在最后的问题

39. ・我们真的需要测试代码么？
・我该测试什么？
・单元测试是在编写双倍代码，减慢了团队的
开发速度么？
・单元测试是否很容易损坏？每次修改代码都
要重写单元测试呢？
・单元测试要追求100%的覆盖率么？
・怎么才能写出可测试的代码？