代码的依赖模块以及测试用例是如何有用的

Example 1:

// constants.js
exports.port = 9865

// constants.test.js
const { port } = require('./constants')
test('port', () => {
  expect(port).toEqual(9865)
})

// app.js
/**
 * 为什么你不对 express 做测试就断定是一个函数?
 * 因为有 express 团队在做背书, 在做单元测试, 保证该模块导出的是一个函数
 * ,你对 express 有充分的相信
 *
 */
const express = require('express')

module.exports = express()

// server.js
/**
 * 其实这里的 app 并不可信, 因为你没有保证 app 导出的是  express()
 * , app.js 需要单测来保证导出的是 express(), 而不是其他的
 * 
 * 同样 server 也并不可信
 * , 因为你没有保证 app.listen 被调用并且传入的是 来自 constants 的 port
 * , 这里需要用测试用例
 *
 * 上面的没有保证, 是没有测试用例的保证, 如果你相信自己不会破坏这个模块
 * , 保证模块的输入输出, 那么它就是可信的
 */
const app = require('./app')
// constants 的输出完全可信, 因为有你自己的单元测试在做背书
// ,这时候你就可以把 ./constants 模块和 express 类比, 可以相信
// ,如果有一个文档就更好了
const { port } = require('./constants') 

/* 这里你同样相信 app 会有一个 listen 函数, 这也是对 express 模块的信任
 * , 所以你不会 typeof app.listen === 'function' && app.listen(...)
 */
app.listen(port, () => {
  console.log(`server is listening at ${port} port.`)
})

所以代码的依赖关系, 就是一个信任的关系, 如果你完全的信任模块 B, 那么模块 A 调用的时候就可以直接调用函数, 获取数据.

怎么样让模块 B 可信, 并在在代码的迭代过程中一直可信?

团队或个人的背书, 充分的单元测试和手动测试, 完善的代码逻辑性.

在写代码的时候经常会想要拆分模块, 那么在拆分模块的时候要用单元测试保证可信. 比如, 你在写一个模块 Foo, 发现 Foo 太过于复杂, 想要将一部分拆分出去成为 Bar, Foo 依赖 Bar, 想好你为什么要拆分, Bar 的输入输出是什么并为之写好单测.

Jiang-Xuan / blog

代码的依赖模块以及测试用例是如何有用的 #13