Download - 前端单元测试
前端单元测试
大纲·单元测试的概念
·为什么要做单元测试
·TDD BDD
·前端单元测试工具
·前端单元测试实战
·留在最后的问题
概念单元测试
断⾔言
用于表达程序设计人员对于系统应达到状态的一种预期,是单元测试的核心部分
对软件中最小可测试单元进行检查和验证
它把对象设置成已知状态,然后运行他们检测出结果,并将其与所预测的结果相对照
实例
为什么要单元测试
前端的现状• javascript语言本身没有提供好的架构模式
• 动态语言的灵活性,导致代码形式多样 • 面向用户,需求灵活多变,需要快速上线 • 很少重构,看不到收益,代码质量没有保障 • 各种浏览器、各种终端让⼈人头疼 • 还有很多头疼的问题
单元测试能够带来什么
能够给予及时反馈
对代码修改或者单元测试出问题后,能够第一时间发现问题,而不是在线上发现
代码质量
·代码质量如何度量
·如果没有测试如何来保证代码质量
回归测试·以前解决了一个BUG,后来又出现了
·发布新版本时,所有功能都要人工测试
重构·在没有单元测试的情况下,怎么做重构
·有可靠的度量来说明重构是否成功么
给你要改变的代码建立一组坚实的测试 -- Martin Fowler
极大减少调试时间单元测试要求代码解耦,针对每个行为单元写用例,所以测试失败更容易找到问题所在位置
促进更好的设计·单元测试要求代码松耦合
·单元测试要求代码接口简单、职责单一
·单元测试要求函数行为明确
⽤用例即⽂文档通过⽤用例可以让代码使⽤用者更容易的理解代码
增强自信心
Test-Driven Development
概念
• 敏捷中常⽤用的⽅方法 • 提倡⽤用测试来驱动应⽤用程序的创建 • 期望短时间内对软件进⾏行渐进式设计
TDD流程
·测试驱动实现,促使每一行代码都可测
·测试作为实现的正确导向,让开发过程更高效
·让应用程序长期处于稳定
TDD的愿景
TDD的问题对设计和测试的编写没有明确的约束
Behavior-Driven Development
·TDD是方法,BDD是规约
·针对行为描述的测试,更具体,更直观
·直白的描述更容易让相关人员介入测试
行为驱动开发,TDD的子集
当⽤用户注册时,应⽤用程序应当接受POST请求,检查字段是否有效,然后将数据库中的⽤用户数递增1作为⼀一个⽤用户,当我成功注册时,我应该看到“感谢注册”
!
• TDD能够保证总是先有测试再有代码且
不断迭代
• BDD能够正确的对系统的行为进行设计
• 两者是互补的
前端测试工具
眼花缭乱的测试框架
Jasmine Mocha Qunit
should chai expect
sinon blanket
jscoverage Vows
JsUnit YUITest JsSpec
组装测试套件
• ⼀一套⽀支持BDD⻛风格的测试框架
• ⼀一套灵活全⾯面,符合习惯的断⾔言库 • ⼀一套代码覆盖率的框架 • 能够⽅方便Stub, Spies, Mock数据的框架
Mocha很不错
• 同时⽀支持浏览器和Node
• 设计灵活,可以选⽤用TDD和BDD的⻛风格
• 可以选⽤用不同⻛风格的断⾔言库 • 很好的⽀支持异步测试 • 详细的⽂文档 • 稳定的社区 • 当然还有明星的作者TJ...
Sinon的能⼒力• Spies
• Stubs
• Mocks
• Fack times
• Fack XHR and server
实战演示
留在最后的问题
·我们真的需要测试代码么?
·我该测试什么?
·单元测试是在编写双倍代码,减慢了团队的开发速度么?
·单元测试是否很容易损坏?每次修改代码都要重写单元测试呢?
·单元测试要追求100%的覆盖率么?
·怎么才能写出可测试的代码?