单元测试范围答案

【问题标题】：Unit test scope单元测试范围
【发布时间】：2011-06-16 12:38:30
【问题描述】：

假设我们有一个远程服务 Alpha，其方法是 GetUser(id, includePurchases)。
该方法具有以下规则：

- 如果 includePurchases 为真，user.Purchases 应该有一个购买列表。
- 如果不是，user.Purchases 应该是空白的。

假设我们有一个网站 Beta，其 UserRepository 有一个 GetUser(id, includePurchases) 方法。
Beta.UserRepository.GetUser() 在内部调用 Alpha.GetUser()。

负责 Alpha 的团队表示，Beta 应该有一个测试来检查该特殊规则。
我不同意，因为如果你有一个调用服务的单元测试，那就是集成测试。

他们不希望 Beta 测试调用 Alpha，而是希望模拟 Alpha.GetUser 方法的测试包含类似“if (includePurchases) user.Purchases = new List()”的内容。
有了这个“如果”，将编写一个断言 user.Purchases 是否为空的测试，具体取决于 includePurchases 标志。

这对你有意义吗？
他们想要的测试，不应该只是 Alpha 单元测试的问题吗？
对我来说，似乎我正在编写一个测试来检查关于 Alpha 工作方式的假设。

【问题讨论】：

在旁注中，我觉得您可能正遭受经典的组件化开发问题，即依赖一个有缺陷的垃圾组件，并且由一个拒绝接受他们完美的团队维护的组件代码可能有问题。但是，当然你有针对你的错误，因为 QA 看不到 Alpha 的问题。这是面向组件的软件开发的典型问题。盖房子的时候，客户会不会去向屋顶工抱怨地基坍塌时没有屋顶？

标签： unit-testing

【解决方案1】：

从组件化的角度来看，这听起来完全正常且合法，是的，您是对的，实际上调用 Alpha 服务的 Beta 单元测试是集成测试。

请记住，如果您正在为 Beta 的功能编写单元测试，那么您将单独负责 Beta 和 Beta。模拟 Alpha 服务调用是合适且首选的，因为您的单元测试应假定这些外部依赖项完全按照宣传的方式工作。

通过模拟 Beta 版中的功能，您可以保证可重复且一致的单元测试可验证 ONLY Beta 版的功能。这样，如果环境中的 Beta 过程失败，并且您的单元测试通过，那么 Alpha Web 服务肯定有问题，然后其他团队有责任解决和修复此错误。

【讨论】：