像盖房子同样写代码：当我以测试驱动开发的时候，我在想些什么

当我写一个功能模块方法时，我在想些什么

// 不管什么方法，都是这样一个结构
const fn = () => {

};

好比，我要写一个接口，查询组织下的设备列表 /api/device/list

地基

const deviceList = (params) => { // 传入一些参数
  return []; // 返回一个列表
};

我须要哪些参数：

• 用户基本信息（主要是用户 id，用户的组织 id）
• 用户对应的组织基本信息（主要是组织 id，组织管理员 id，层级关系，以及权限逻辑）

输出结果很简单，为一个数组。

浇筑

第一步分析，存在成功和错误（错误类型先不考虑）两种类型的结果。

// 成功
// 错误
const deviceList = async (ctx) => {
  // 错误
  if(someError) {
    // 返回错误结果
  }
  // 成功
  return getDevicesByOid(oid);
};

这是一个大概的设想，没有必要将代码写出来。而后润化该思路，写出第一段框架。

主体结构

首先，传入的参数为组织 oid，用户的信息能够经过 session（或其余方式）从内部得到。

可能的一种思路

// 成功
// 错误
// 错误1：用户未加入组织
// 错误2：传入参数组织不存在
// 错误3：用户无组织权限

// 传入参数： 要查询的组织 oid
// 可以经过 session 取到的信息： user
const deviceList = async (ctx) => {
  // 用户信息 ctx.user
  // 判断用户是否有组织
  if (ctx.user.oid === 0) {
    // 错误1：用户未加入组织
  }

  // 若是不传该参数，查询当前用户组织的设备
  const { oid = ctx.user.oid } = ctx.request.body;
  if (oid === ctx.user.oid) {
    // 成功
    return getDevicesByOid(oid);
  }

  // 根据oid查询组织信息
  // 错误2：传入参数组织不存在
  // 判断是否有权限
  const checkRights = await checkUserOrgRights(ctx.user.uid, oid);
  if (!checkRights) {
    // 错误3：用户无组织权限
  }
  // 成功
  return getDevicesByOid(oid);
};

推荐的实现方式

// 成功
// 错误
// 错误1：用户未加入组织
// 错误2：传入参数组织不存在
// 错误3：用户无组织权限

// 传入参数： 要查询的组织 oid
// 可以经过 session 取到的信息： user
const deviceList = async (ctx) => {
  // 用户信息 ctx.user
  // 判断用户是否有组织
  if (ctx.user.oid === 0) {
    // 错误1：用户未加入组织
  }

  // 若是不传该参数，查询当前用户组织的设备
  const { oid = ctx.user.oid } = ctx.request.body;
  if (oid !== ctx.user.oid) {
    // 为何这里不用等于判断：若是等于的话，则当时就须要返回出去，这样的话该方法会有两个成功的 return
    // 根据oid查询组织信息
    // 错误2：传入参数组织不存在
    // 判断是否有权限
    const checkRights = await checkUserOrgRights(ctx.user.uid, oid);
    if (!checkRights) {
      // 错误3：用户无组织权限
    }
  }
  // 成功
  return getDevicesByOid(oid);
};

封顶

完成其余的业务代码。

当我写一段测试的时候，我在想些什么

按照上面推荐方式完成代码后，须要进行代码的测试。

首先须要明确业务的流程，理清测试的思路。

• 成功

• 错误

  • 错误1：用户未加入组织
  • 错误2：传入参数组织不存在
  • 错误3：用户无组织权限

主要有两种设计思路：

设计思路

思路一

1. 完成测试用例，覆盖成功的全部状况
2. 完成测试用例，覆盖错误1的全部状况
3. 完成测试用例，覆盖错误2的全部状况
4. 完成测试用例，覆盖错误3的全部状况

这是传统的单元测试衍生而来的 BDD 测试方式。

这里测试用例的个数应该为8次：

• 成功：

  • 1.当前组织的用户有传入组织 oid
  • 2.当前组织的用户未传入组织 oid
  • 3-5.上级组织，上上级组织，根级组织的管理员用户传入组织 oid
• 6.失败1：用户未加入组织
• 7.失败2：传入参数组织不存在
• 8.失败3：用户无组织权限

其中，测试3-5能够优化为一次测试（即根据全部管理员 uid 的数组比较是否包含当前用户 uid），最终优化后的结果应当为6次。

但因为该思路中不明确用户，因此用户行为没法准确表达，在建立测试数据的时候较为困难，不仔细思考分析，没法优化须要建立多少条测试数据。

思路二

而实际上 BDD 测试为用户行为测试，能够以几类用户的情形分别进行测试。

1. 模拟一个用户的数据，覆盖成功和可能错误（有可能没法涵盖到全部错误）的全部状况
2. 根据未覆盖的部分，再模拟另外一个用户的数据，覆盖成功和可能错误（有可能没法涵盖到全部错误）的全部状况

以此循环，直至覆盖全部。

• 用户1（非组织管理员，查询本身的组织）

  • 1.成功（未传入组织 oid）（组织1）
  • 2.成功（传入组织 oid）
  • 3.失败2：传入参数组织不存在
  • 4.失败3：用户无组织权限（组织2）

• 用户2（上级某组织管理员）（组织3）

  • 5.成功

• 用户3（未加入组织用户）

  • 6.失败1：用户未加入组织

很是简洁明了的关系，须要3个测试用户，3个组织（上下级关系进行数据复用，一个无权限的组织），便可涵盖全部范围。

最终优化版设计：

• 用户1（某组织管理员，有下级组织）

  • 1.成功（未传入组织 oid，查询本身的组织）
  • 2.成功（传入当前的组织 oid（组织1））
  • 3.成功（传入下级的组织 oid（组织2））
  • 4.失败2：传入参数组织不存在
  • 5.失败3：用户无组织权限

• 用户2（未加入组织用户）

  • 6.失败1：用户未加入组织（组织3）

两个用户，三个组织。完成全部覆盖。

当我以测试驱动开发的时候，我在想些什么

能够从上述测试思路二中进行反推。

实际上思路多是在写代码或者写测试的过程当中不断的改进和完善的。

• 若是已经写好了测试正在写代码，能够及时回过头来调整测试；
• 若是功能写好了又再从新测试，能够在测试优化后再去看逻辑代码是否还有优化的空间。

更多关注： https://leader.js.cool/#/expe...