前端单元测试

大纲·单元测试的概念

·为什么要做单元测试

·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%的覆盖率么？

·怎么才能写出可测试的代码？