单元测试范围

时间:2011-06-16 12:38:30

标签: unit-testing

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

  - 如果includePurchases为true,则user.Purchases应该有一个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()”的内容。
使用“if”,将编写一个断言用户的测试。根据includePurchases标志,购买是否为空。


这对你有意义吗? 他们想要的测试应该不仅仅是Alpha单元测试的关注点吗? 对我而言,似乎我正在编写一个测试,检查Alpha工作方式的假设。

1 个答案:

答案 0 :(得分:6)

从组件化的角度来看,这听起来非常正常和合法,是的,你是对的,实际调用Alpha服务的Beta单元测试是集成测试。

请记住,如果您正在为Beta的功能编写单元测试,那么您仅负责Beta和Beta。模拟Alpha服务调用是合适的,也是首选,因为您的单元测试应该假设这些外部依赖项的工作方式与广告中的相同。

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