如何划分Acceptance tests与Unit tests的测试场景及相关疑问

一、清晰的判定标准 #

直接从两个核心维度划界，避免模糊：

1. 视角与目标
   • 验收测试：站在用户/业务方视角，验证系统是否满足业务需求（即WHAT）——核心是「做正确的事」。用自然语言描述业务场景，比如「用户添加标注为‘playing’的游戏，系统应成功存入并返回确认信息」。
   • 单元测试：站在开发者视角，验证单个代码单元（函数、类、模块）的逻辑是否正确（即HOW）——核心是「正确地做事」。针对具体实现细节，比如「校验游戏状态的函数，传入‘invalid’时应抛出参数错误」。
2. 覆盖范围与粒度
   • 验收测试：覆盖业务规则的核心路径+关键边界，不关心内部实现，只看最终输出（API响应、数据库状态等）。
   • 单元测试：覆盖代码逻辑的所有分支，包括细粒度的边界情况，聚焦单个单元的独立行为。

二、游戏库API场景下的测试划分 #

验收测试（BDD）覆盖场景 #

用业务视角的场景描述（可对应Given-When-Then格式）：

• 正常流程：用户已登录，提交状态为「playing」的游戏信息，系统返回成功状态，游戏库新增该记录。
• 关键业务边界：用户已登录，尝试添加已存在的游戏，系统返回「游戏已存在」错误；提交用户名长度小于3/大于20的请求，系统返回参数错误；提交空密码的请求，系统返回「密码不能为空」错误。
• 状态合法性校验：用户已登录，提交状态为「invalid」的游戏，系统返回「状态不合法」错误。

单元测试（TDD）覆盖场景 #

针对具体代码单元的逻辑细节：

• 游戏状态校验函数：测试传入「playing」「played」「plan to play」时返回合法，传入其他字符串时抛出异常。
• 游戏去重逻辑：测试游戏ID相同、名称相同但ID不同、名称+平台组合相同等场景下的去重判断是否正确。
• 用户名校验工具：测试长度为2（不合法）、3（合法）、20（合法）、21（不合法）、空字符串等所有分支的返回结果。
• 密码校验逻辑：测试空字符串、长度小于6、长度等于6、长度大于20等场景的校验结果。
• API请求处理模块：测试当底层校验函数抛出异常时，是否正确封装为对应HTTP错误码返回。

三、边界场景的重复问题：互补而非冗余 #

验收测试和单元测试的边界场景覆盖是各司其职，无需完全重复：

• 验收测试只验证业务层面的最终结果，比如「用户名过长时无法添加游戏」——只要确认API返回错误即可，不用关心底层判断逻辑。
• 单元测试需要覆盖代码实现的所有细粒度分支，比如用户名长度刚好达阈值、超过阈值、包含特殊字符等所有情况，确保校验逻辑无漏洞。

举个具体例子：

• 验收测试：仅用一个长度超过20的用户名验证「添加失败」的结果即可。
• 单元测试：要测长度20（合法）、21（不合法）、空（不合法）、含空格（是否合法依业务规则）等所有分支，确保校验函数逻辑完全正确。

内容的提问来源于stack exchange，提问作者Jordi Pagès