单元测试的粒度

最近在写 qduoj 的测试，但是写起来实在是不容易，因为很多测试可以写的很细也可以写的很粗。比如说测试用户注册功能，认真的写的话可能要考虑以下测试用例

• 错误的数据格式，比如非 json 数据，比如缺少字段等
• 验证码错误的提示
• 数据格式问题，比如用户名密码长度、邮箱格式等
• 用户名或邮箱已经存在的提示
• 注册成功的提示
• 提示注册成功，数据库里面是否真的有这个用户
• 登录成功后返回的个人信息里面的内容是否正确

如果真的这样去写就太耗时耗力了，毕竟这个产品还是能容忍发生一些问题的，而不是像航空航天一样，真的不能发生一点问题。

其实关于单元测试的粒度的问题，早就有人在讨论了。 http://coolshell.cn/articles/8209.html

我的观点是区分优先级和重要程度就行。

• 首先要明确你要测试什么模块，这个模块应该是相对独立的，可以单独测试的。比如这个地方是用户注册模块。
• 然后是这个功能中有哪些功能，这个地方功能就一个，用户提交数据注册。
• 然后这个功能中有哪些点是重要的，需要写测试保证的，出了问题会产生相对严重的后果的。有哪些点是一般的，不容易出错的，即使出错也没什么问题的。剩下的就可以认为是不会出错的，可以不进行测试。
• 优先对第一个点进行测试，剩下的两个可以看时间来完成。

这样的话，肯定不是 TDD 了，而且100%的测试覆盖率也不可能达到，当然大家也都知道100%的测试覆盖率也是自欺欺人的。

按照这样的原则，上面的用户注册的测试用例就分成这样三部分了，

必须要测试的

• 验证码错误的提示
• 数据格式问题，比如用户名密码长度、邮箱格式等
• 用户名或邮箱已经存在的提示

有空就写的

• 提示注册成功，数据库里面是否真的有这个用户

无所谓的

• 注册成功的提示
• 登录成功后返回的个人信息里面的内容是否正确
• 错误的数据格式，比如非 json 数据，比如缺少字段等

FROM :strcpy.me | Author:strcpy