用 jest 单元测试改善老旧的 Backbone.js 项目

对于早期的前端 SPA 项目,Backbone.js + Require.js 是一种常见的技术组合,分别提供了基础的 MVC 框架和模块化能力。

对于这样的既有项目,在之前的文章中也进行过分析,常常面临依赖不清、封装混乱,以及缺乏测试等问题;对之进行维护和新需求开发时,结合其本身特点,在 TDD 的方式下进行渐进的改善,而非推倒重来,无疑是个可行的办法。

本文将尝试用一个重构实例来抛砖引玉,讲解如何对其应用较新的 jest 测试框架,并用 ES6 class 等新手段升级 Backbone.View 视图组件和改善页面结构,希望能对类似项目的改善起到开启思路的作用。

关于测试、重构的各种概念,不再重复介绍;请先参阅以下文章:

Backbone.js / Require.js 技术栈回顾

Require.js 模块化

首先说 Require.js,在没有 webpack 的日子里,这是最常见的模块化管理工具。

其本身可以提供 AMD 规范的 JS 模块,并提供了通过插件加载文本模板等能力。

在实际的项目中,我们采用了 ES6 语法和 ESM 模块规范来编写源文件,并借助 babel 将其转译为 UMD 模块;最后通过 Require.js 提供的优化工具 来打包,并由 Require.js 本身在浏览器里实现模块的加载。

当然,采用 ES6语法 和 babel 并非一定必要,AMD 也是可以实现测试的。

Backbone.js

不同于提供整套方案的 Angular 的是, Backbone.js 提供了一个非常基础和自由的 MVC 框架结构,不仅可以用多种方式组织项目,也可以自由替换其中的某一部分。

其主要功能模块包括:

Events:提供一系列事件的绑定和触发等功能

Model: 对数据或状态的转化、校验、计算派生值、提供访问控制等,也负责数据的远程同步等,并有事件触发机制;作用类似于 MobX

Collection: Model 的集合

Router: 提供了 SPA 的前端路由功能,支持 hashChange 和 pushState 两种方式

Sync: 一些远程请求的方法

View: 可以拼装模板数据、绑定事件等的视图组件

在我们的实际项目中,视图层同时支持了 Backbone.View 和早期的 react@13,这也正体现了其灵活之处。

通常的 Backbone 项目也可以忽略文中涉及 react 的部分。

升级测试框架

和之前文章中的例子相同,本次依然采用 Jest 作为测试框架。

原有用例

早期的项目中其实是有一些单元测试代码的,主要是用 Jasmine 对部分 model/collection 进行了测试。由于 Jest 内置了 Jasmine2,所以这部分的语法问题不大,基本可以无痛迁移。

早先测试的主要问题在于:

一是没有整合到工作流中,采用单独的网页作为载体,久而久之就会遗忘这个步骤,用例可能失效,新加入的团队成员也不会注意到这项工作的存在

二是当时对 model/collection 的单元测试并不严谨,依赖了提供 mock 数据的 php 服务器环境

三是由于视图层没有很好的组件化,从而缺乏对视图组件的测试

jest for Backbone 的实践

jest 是比较新的测试框架,默认零配置,但也提供了灵活的适配方法,可以适应各种项目,包括 Backbone.js 的情况。

这位 @captbaritone 小哥提供了一个很好的讲解视频 (需要科学上网 https://www.youtube.com/watch?v=BwzjVNTxnUY&t=15s),并且配上了实例代码(https://github.com/captbaritone/tdd-jest-backbone)。

配置必要的依赖和映射

配置两种 npm script,分别用于开发时实时运行测试和 build 时运行测试

目标项目中,其实是用 babel 5 做的 ES6 转译;但是由于之前的源代码已经全部采用了 ES6 语法开发(部分初始 AMD 代码也做过自动转化),所以我们完全可以在测试时采用较新的 babel 6

加入对老版本 react 的支持

根据目标项目的情况采用了 enzyme-adapter-react-13 做适配

用 cross-env 设置环境变量 test,从而配置出适用于 jest 的 .babelrc 文件,且不影响生产环境

根据项目中的具体情况,按原来的规则做好组件名称的映射

将单元测试加入到 build 任务

如果只写好了测试,而单独存在,只能用 执行的话,那就重蹈了原来的覆辙;这里借助 插件将其加入已有的 工作流:

这样在之后的 build 任务中,一旦有单元测试未通过,整个流程将停止执行。

测试 model 和 collection

一个 model 大概长这个样子:

在测试中注入全局 url 前缀

可以发现 model 中依赖了以个全局变量中的属性

首先编写一个假的全局对象:

测试套件中,在 model 之前引入这个模块就可以了:

用 sinon 拦截异步请求

搞定了异步请求的地址,自然要拦截真正的请求;

Backbone 中的请求,包括 Backbone.sync / model.fetch() 等, 本质上还是调用的 jQuery 中的 方法(默认情况下),也就是传统的 xhr 方式,使用 sinon 就可以很好的胜任这种暗度陈仓的工作:

校验操作的测试

调用 Backbone.Model 实例的 isValid() 方法,会得到数据是否有效的布尔值结果,同时触发内部的 validate() 方法,并更新其 validationError 的值;利用这些特性,我们可以做如下测试:

collection 的测试和 model 相比并无特别,不再赘述

view 之必然的 testable 组件化

开篇提到过,项目中以前的过时测试用例中,是缺少 view 视图层部分的。

这一方面是囿于当时测试意识的不足,更主要的原因是没能很好解决组件化的问题。

要对 view 进行测试,就得将其拆分重构为功能明确、便于复用的各种小型组件。

Backbone.View 的 ES6 class 进化

首先进行的,是类似于 React.createClass 向 class extends Component 的进化,Backbone.View 也是可以华丽转身的。

传统的 view 写法是这样的:

采用 ES6 class 的写法,则可能是:

组件的提取

目标项目的很多页面,没有合理的封装出子组件,而仅仅是把需要复用部分的 html 提取成模板,在本页面“拼装”多个子模板,或和其他页面复用。这部分归因于 Backbone 的“过分自由”,官网或者当时的通用实践中并未给出很好的组件化方案,只是停留在用依赖的 underscore 实现 _.template() 的阶段。

另一个难点在于,Backbone.View 的 constructor / initialize “构造函数”中,并不能接受自定义的 props 参数。

解决的办法是进行一定的外层封装:

也可以“继承”一个 View:

在页面中使用时,先传参获取到真正的 Backbone.View 组件:

再手动调用其 render() 方法并加入页面视图的 DOM 中:

这样就在很大程度上实现了 Backbone.View 组件的封装和嵌套。

测试 Backbone.View 组件

比之于测试 react 还需要 enzyme 等的支持,测试 Backbone.View 其实要简单许多,只需要获取到其 $el 属性,调用 jQuery 的惯有方法即可:

对方法调用的测试

自然还是用 sinon 来做:

处理用 require.js 的 text 插件引入的模板

Backbone.js + Require.js 在测试中的一个小问题是:页面或组件中一般会用 text.js 组件引入模板,其 ES6 形式为:

因为测试环境没有 require.js 或者 webpack 的加持,我们只能想办法将其劫持,并将正确的结果注入对应的测试模块中;

要实现这一目的,就要用到 方法,其缺点是用了这个就不能用 ES6 的 import 语法了,配置和使用简要说明如下:

总结

jest 灵活的配置能力,使其能方便的应用于各种类型既有项目的 TDD 开发和重构

之前的其他测试框架下的用例,可以快速迁移到 jest 中

Backbone.View 视图组件在经过 ES6 升级和合理封装后,可以明显改善页面的整洁度,并顺利应用于单元测试

可以用 sinon.createFakeServer() 拦截 Backbone.Model 中的异步请求

原来用 Require.js 下的 text.js 组件引入的模板,也可以用 jest.doMock() 很好的支持

将单元测试任务加入原有的 build 工作流,可以保证相关代码之后的持续有效

(end)

-------------------------------------

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180307G0LAW100?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券