文章目录
- 3.4 函数式依赖注入技术 Functional injection techniques
- 3.5 模块化依赖注入技术 Modular injection techniques
写在前面
上一篇的最后部分对第三章后续内容做了一个概括性的梳理，并给出了断开依赖项的最简单的实现方案，函数参数值注入法。本篇接着介绍函数式注入与模块化注入的具体实现。窃以为后者是本章的难点，需要用心体会作者的设计思路。
（接 上篇 3.3 小节）
3.4 函数式依赖注入技术 Functional injection techniques
函数式实现（FP）与面向对象实现（OOP）并无绝对的优劣之分。FP 固然简洁、清晰、自证性强，但学习曲线陡峭也是不争的事实。
上一节讲到断开外部依赖的一种方案——参数注入法。它通过重构原函数，使其接收一个新参数值（即人为控制的星期索引值）。但这里的参数除了基本类型外，还可以将具体星期值的计算逻辑封装到一个函数内，然后将该函数以参数的形式注入原函数。
于是有了函数式注入的第一套方案——函数作参数注入。对原函数模块 password-verifier-time00.js 作如下更改（L2、L3）：
const SUNDAY = 0, SATURDAY = 6;
const verifyPassword3 = (input, rules, getDayFn) => {
const dayOfWeek = getDayFn();
if ([SATURDAY, SUNDAY].includes(dayOfWeek)) {
throw Error("It's the weekend!");
}
// more code goes here...
// return list of errors found..
return [];
};
于是单元测试 password-verifier-time00.spec.js 相应变为（L4、L5，以及 L9、L11）：
const SUNDAY = 0, SATURDAY = 6, MONDAY = 2;
describe('verifier3 - dummy function', () => {
test('on weekends, throws exceptions', () => {
const alwaysSunday = () => SUNDAY;
expect(() => verifyPassword3('anything', [], alwaysSunday))
.toThrowError("It's the weekend!");
});
test('on week days, works fine', () => {
const alwaysMonday = () => MONDAY;
const result = verifyPassword3('anything', [], alwaysMonday);
expect(result.length).toBe(0);
});
});
实测结果：
【图 5 改为函数作参数后的实测结果】
再进一步，可将传入的函数改造为一个高阶函数（high order function，简称 HOF），让依赖注入逻辑与密码校验逻辑分开。这样就有了书中所说的 工厂函数（factory functions） 方案。此时原函数已经被完全改造了。
password-verifier-time00.js：
const SUNDAY = 0, SATURDAY = 6;
const makeVerifier = (rules, dayOfWeekFn) => {
return function (input) {
if ([SATURDAY, SUNDAY].includes(dayOfWeekFn())) {
throw new Error("It's the weekend!");
}
const errors = [];
// more code goes here..
return errors;
};
};
module.exports = {
makeVerifier
};
于是单元测试 password-verifier-time00.spec.js 也要同步更新：
const { makeVerifier } = require('../password-verifier-time00');
const SUNDAY = 0, MONDAY = 1;
describe('verifier3 - dummy function', () => {
test('factory method: on weekends, throws exceptions', () => {
const alwaysSunday = () => SUNDAY;
const verifyPassword = makeVerifier([], alwaysSunday);
expect(() => verifyPassword('anything'))
.toThrow("It's the weekend!");
});
test('on week days, works fine', () => {
const alwaysMonday = () => MONDAY;
const verifyPassword = makeVerifier([], alwaysMonday);
const result = verifyPassword('anything');
expect(result.length).toBe(0);
});
});
实测结果同上面的 图 5。这样做的好处，就是让校验的配置独立于校验的执行，在减少原函数参数个数的同时，测试用例的可读性也更强。一举多得。
3.5 模块化依赖注入技术 Modular injection techniques
这一节开始加大难度了，主要目的在于让大家感受一下模块化注入的繁琐。为什么会这么繁琐呢？因为以模块的方式注入依赖项虽然写起来很爽，但对于单元测试而言完全是另一码事。回到最开始的原函数版本——
password-verifier-time00.js：
const moment = require("moment");
const SUNDAY = 0, SATURDAY = 6;
const verifyPassword = (input, rules) => {
const dayOfWeek = moment().day();
if ([SATURDAY, SUNDAY].includes(dayOfWeek)) {
throw Error("It's the weekend!");
}
// more code goes here...
// return list of errors found..
return [];
};
module.exports = {
verifyPassword,
};
怎样从单元测试的角度断开上述代码中的直接依赖呢？答案是没有现成的方法，只能“曲线救国”。这就要用到 3.2 节补充的 Seam 缝隙的概念了：通过构造一个特定的写法，以便将直接依赖项替换成单元测试能够直接干预的代码，实现 控制反转。
以下代码给出了一个示例版本：
核心重构1：根据模块化注入方案重构的新版待测函数示例
const originalDependencies = {
moment: require('moment')
};
let dependencies = { ...originalDependencies };
const inject = (fakes) => {
Object.assign(dependencies, fakes);
return function reset () {
dependencies = { ...originalDependencies };
};
};
const SUNDAY = 0; const SATURDAY = 6;
const verifyPassword = (input, rules) => {
const dayOfWeek = dependencies.moment().day();
if ([SATURDAY, SUNDAY].includes(dayOfWeek)) {
throw Error("It's the weekend!");
}
// more code goes here...
// return list of errors found..
return [];
};
module.exports = {
SATURDAY,
verifyPassword,
inject
};
相比其他小节，上述代码是本章最难的一段。原因很简单——我之前从没这样认真研究过（开个玩笑 😆）。
先来仔细看看这段代码。为了成功断开由 moment.js 引入的直接依赖，需要构造一个新的写法，即第 17 行中的星期值生成逻辑：
// 改造前：
const dayOfWeek = moment().day();
// 改造后：
const dayOfWeek = dependencies.moment().day();
先甭管 dependencies 怎么定义的，写成第 4 行的形式后，最初的 moment().day() 就变成了 dependencies 下的 moment() 方法；这时，只要再设计一个注入逻辑（比如第 7 至 12 行的 inject(fakes) 函数），并让它在运行测试时对 dependencies.moment 属性 重新赋值，这样就实现了原始依赖 moment 模块的平替，从而实现 控制反转；最后，为了不破坏原函数逻辑，等到单元测试结束，还得再设计一套 重置逻辑，让 dependencies.moment 重新指向 moment 模块。这就是模块化注入的大致流程。
与之配套的单元测试代码如下：
核心代码2：模块化改造后的新校验函数在单元测试模块中的应用示例
const { inject, verifyPassword, SATURDAY } = require('../password-verifier-time00');
const injectDate = (newDay) => {
const reset = inject({
moment: function () {
// we're faking the moment.js module's API here.
return {
day: () => newDay
};
}
});
return reset;
};
describe('verifyPassword', () => {
describe('when its the weekend', () => {
it('throws an error', () => {
const reset = injectDate(SATURDAY);
expect(() => verifyPassword('any input'))
.toThrowError("It's the weekend!");
reset();
});
});
});
第一次看这两段代码，头是真的晕。比如上面的高阶函数 injectDate()：它接收一个普通的星期值 newDay，然后用这个值构造了一个测试专用的伪对象 fakes（示例中没有单独声明）并直接传入 inject() 方法，最后将执行结果——即包含重置逻辑的 reset() 函数——作为函数结果返回。最后在测试用例的第 18 行和第 23 行实现了控制的反转与依赖项的重置。
抱着将信将疑的心理，我在本地实测了上述代码，居然真的可以这样写：
【图 6 按照模块化注入方案重构原函数得到的实测结果】
正当我惊叹于作者对 JavaScript 闭包的深入理解时，大佬又再次复盘上述写法，对比了该方案的优劣：
- 优势：解决了最开始的直接依赖问题，使用时也相对比较简单（按大佬的说法，多写几遍自然就有感觉了……）；
- 劣势：即闭包
dependencies中的moment属性与依赖的moment模块之间未能实现解耦。遇到真实项目测试就傻眼了：成千上万个依赖项接口难不成还得挨个重构成特定的闭包属性？
为此，作者给出了如下建议：
- 永远不要在代码中直接使用第三方依赖，最好加一个适配层缓冲一下，这样就不怕第三方库修改接口或者更换其他依赖项了。
- 慎用这个天坑的模块注入方案，换成其他实现方案，比如之前介绍的视函数为参数、或者函数柯里化；或者后面紧接着会介绍的 构造函数 以及 接口 的解决方案。
总之，这一节主要是给后续的高级方案做铺垫用的；对我而言也是增长见识的一节，让我知道设计模式中的适配器模式在单元测试中原来还能这么用。
