当我写一个功能模块方法的时候，我在想什么//不管是什么方法，都是这样一个结构体constfn=()=>{};比如我想写一个接口查询组织/api/device/list基础下的设备列表constdeviceList=(params)=>{//传入一些参数return[];//返回一个列表};我需要什么参数：用户基本信息（主要是用户id、用户组织id）用户对应的组织基本信息（主要是组织id、组织管理员id、层级关系、权限逻辑）输出结果就是一个简单的数组。在第一步浇注的分析中，有两种结果：success和error（error类型先不考虑）。//成功//错误constdeviceList=async(ctx)=>{//错误if(someError){//返回错误结果}//成功returngetDevicesByOid(oid);};这是一个大概的思路，没必要把代码写出来。然后提炼思路，写出框架的第一段。主要结构首先，传入的参数是组织oid，可以通过session（或其他方式）在内部获取用户的信息。一种可能的思路//成功//错误//错误1：用户没有加入组织//错误2：传入的参数组织不存在//错误3：用户没有组织权限//传入parameter:要查询的组织oid//通过session可以得到的信息：userconstdeviceList=async(ctx)=>{//用户信息ctx.user//判断用户是否是组织if(ctx.user.oid===0){//错误1：用户没有加入组织}//如果不传该参数，则查询当前用户组织的设备const{oid=ctx.user.oid}=ctx.请求体；if(oid===ctx.user.oid){//成功返回getDevicesByOid(oid);}//根据oid查询组织信息//错误2：传入参数组织不存在//判断是否有权限constcheckRights=awaitcheckUserOrgRights(ctx.user.uid,oid);if(!checkRights){//错误3：用户没有组织权限}//成功returngetDevicesByOid(oid);};推荐实现//成功//错误//错误1：用户没有加入组织//错误2：传入参数组织不存在//错误3：用户没有组织权限//传入参数：组织需要查询的oid//通过session可以得到的信息：userconstdeviceList=async(ctx)=>{//用户信息ctx.user//判断用户是否有组织if(ctx.user.oid===0){//错误1：用户没有加入组织}//如果不传该参数，则查询当前用户组织的设备const{oid=ctx.user.oid}=ctx.request.body;if(oid!==ctx.user.oid){//这里为什么不做相等判断：如果相等，那时候需要返回，所以这个方法会有两次成功返回//根据oid查询组织信息//错误2：传入参数组织不存在//判断是否有权限constcheckRights=awaitcheckUserOrgRights(ctx.user.uid,oid);if(!checkRights){//错误3：用户没有组织权限}}//成功返回getDevicesByOid(oid);};加盖完成其他业务代码当我写测试的时候，我在想什么？按照上面推荐的方式完成代码后，我需要测试代码。首先要理清业务流程，理清测试思路。Success错误错误1：用户未加入组织错误2：传入参数组织不存在错误3：用户没有组织权限完成错误1的所有用例测试，覆盖错误2的所有用例完成测试用例，并覆盖错误3的所有用例。这是一种从传统单元测试衍生出来的BDD测试方法。这里测试用例的次数应该是8次：成功：1、当前组织的用户有一个传入的组织oid2。当前组织的用户没有在组织oid3-5中传入。上级组织、上级组织、根级组织管理员用户传入组织oid6.失败1：用户未加入组织7.失败2：传入参数organization加入notexist8.失败3：用户没有组织权限其中，测试3-5可以作为测试进行优化（即根据所有管理员uid数组比较包含当前用户uid），最终优化结果应该是6倍。但是，由于该思路没有明确定义用户，无法准确表达用户行为，也难以创建测试数据。如果不仔细考虑和分析，就不可能优化需要创建多少条测试数据。思路2BDD测试其实就是用户行为测试，可以在几类用户的情境下进行测试。模拟一个用户的数据，覆盖成功和可能的错误（可能不会覆盖所有错误）根据未覆盖的部分，模拟另一个用户的数据，覆盖成功和可能的错误（可能不会覆盖所有错误））在此循环，直到覆盖所有情况。用户1（非组织管理员，查询自己的组织）1.成功（组织oid未传入）（组织1）2.成功（组织oid传入）3.失败2：传入的参数组织不存在4.失败3：用户没有组织权限（组织2）用户2（上级组织的管理员）（组织3）5、成功用户3（未加入组织的用户）6、失败1：用户未加入组织organization非常简洁明了的关系，需要3个测试用户，3个组织（数据复用从属关系，1个组织无权限），可以涵盖所有范围。最终优化版本设计：用户1（下属组织的组织管理员）1.成功（组织oid中没有传入，查询自己的组织）2.成功（当前组织oid中传入（组织1））3.成功（传入下级组织oid（组织2））4.失败2：传入参数组织不存在5.失败3：用户没有组织权限User2（未加入组织的用户）6.失败1：用户没有加入组织（组织3）两个用户，三个组织。完成所有覆盖。我在使用测试驱动开发的时候，就在思考上面第二个测试思路可以逆向什么。其实这个idea可能在写代码或者写测试的过程中不断的完善和完善。如果已经写完测试，正在写代码，可以及时回过头来调整测试；如果是写了功能再重新测试，可以在测试优化后检查逻辑代码是否有优化的空间。更多关注：https://leader.js.cool/#/expe...
