像盖房子一样写代码

快来打我* 2022-02-01 10:19 291阅读 0赞

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

1.  `// 无论什么方法，都是这样一个结构`
2.  `const fn = () => {`
3.   
4.  `};`

比如，我要写一个接口，查询组织下的设备列表 /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.  `// 错误1：用户未加入组织`
4.  `// 错误2：传入参数组织不存在`
5.  `// 错误3：用户无组织权限`
6.   
7.  `// 传入参数： 要查询的组织 oid`
8.  `// 能够通过 session 取到的信息： user`
9.  `const deviceList = async (ctx) => {`
10. ` // 用户信息 ctx.user`
11. ` // 判断用户是否有组织`
12. ` if (ctx.user.oid === 0) {`
13. `   // 错误1：用户未加入组织`
14. ` }`
15.  
16. ` // 如果不传该参数，查询当前用户组织的设备`
17. ` const { oid = ctx.user.oid } = ctx.request.body;`
18. ` if (oid === ctx.user.oid) {`
19. `   // 成功`
20. `   return getDevicesByOid(oid);`
21. ` }`
22.  
23. ` // 根据oid查询组织信息`
24. ` // 错误2：传入参数组织不存在`
25. ` // 判断是否有权限`
26. ` const checkRights = await checkUserOrgRights(ctx.user.uid, oid);`
27. ` if (!checkRights) {`
28. `   // 错误3：用户无组织权限`
29. ` }`
30. ` // 成功`
31. ` return getDevicesByOid(oid);`
32. `};`

**推荐的实现方式**

1.  `// 成功`
2.  `// 错误`
3.  `// 错误1：用户未加入组织`
4.  `// 错误2：传入参数组织不存在`
5.  `// 错误3：用户无组织权限`
6.   
7.  `// 传入参数： 要查询的组织 oid`
8.  `// 能够通过 session 取到的信息： user`
9.  `const deviceList = async (ctx) => {`
10. ` // 用户信息 ctx.user`
11. ` // 判断用户是否有组织`
12. ` if (ctx.user.oid === 0) {`
13. `   // 错误1：用户未加入组织`
14. ` }`
15.  
16. ` // 如果不传该参数，查询当前用户组织的设备`
17. ` const { oid = ctx.user.oid } = ctx.request.body;`
18. ` if (oid !== ctx.user.oid) {`
19. `   // 为什么这里不用等于判断：如果等于的话，则当时就需要返回出去，这样的话该方法会有两个成功的 return`
20. `   // 根据oid查询组织信息`
21. `   // 错误2：传入参数组织不存在`
22. `   // 判断是否有权限`
23. `   const checkRights = await checkUserOrgRights(ctx.user.uid, oid);`
24. `   if (!checkRights) {`
25. `     // 错误3：用户无组织权限`
26. `   }`
27. ` }`
28. ` // 成功`
29. ` return getDevicesByOid(oid);`
30. `};`

**封顶**

完成其他的业务代码。

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

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

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

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

主要有两种设计思路：

**思路一**

*  完成测试用例，覆盖成功的所有情况
 *  完成测试用例，覆盖错误1的所有情况
 *  完成测试用例，覆盖错误2的所有情况
 *  完成测试用例，覆盖错误3的所有情况

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

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

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