Skip to content

MOCK-UNIT-TESTING.md.md

Latest commit

 

History

History
31 lines (23 loc) · 2.4 KB

MOCK-UNIT-TESTING.md.md

File metadata and controls

31 lines (23 loc) · 2.4 KB

测试中的"伪装术"(mock仿件,stubs桩件)

伪装术(mock仿件,stubs桩件)描述

有时候对被测系统(mock仿件、stubs桩件)进行测试是很困难的,因为它依赖于其他无法在测试环境中使用的对象、组件、或者api.这有可能是因为这些(对象、组件、api)不可用,它们不会返回测试所需要的结果,或者执行它们会有不良副作用.在其他情况下,我们的测试策略要求对被测系统的内部行为有更多控制或更多可见性. 如果在编写测试时无法使用(或选择不使用)实际的依赖组件,可以用测试替身来代替.测试替身不需要和真正的依赖组件有完全一样的的行为方式；他只需要提供和真正的组件同样的 API 即可,这样被测系统就会以为它是真正的组件!

什么情况下使用(mock仿件、stubs桩件、)

  • 1.如果外部依赖不存在,则测试肯定无法通过
  • 2.如果外部依赖不会返回测试所需的结果,或者执行它会有不良的副作用.
  • 3.如果外部依赖变更,则会导致测试失败.严格来说这种后果不是测试的责任,外部依赖的变更应该保持外部接口不变和返回结果不变,只变更内部的行为.使用伪装术的好处就在于一旦出现这种情况不至于让你误以为是己方的代码出了问题.当然你也会想,如果用了伪装对象,那么外部依赖变了己方的测试还浑然不知,这不是很危险吗?有道理,不过单元测试的职责是测试己方代码的正确性,对于外部依赖的模拟不一定非得和模拟对象完全一致,真实的交互应该先由集成测试来捕捉问题,否则很容易迷失在复杂的代码交互之中.

例如：

1.我在编写单元测试Cart购物车类,依赖Product产品类和User用户类
2.依赖Product产品类和User用户类已经测试过了
3.或者依赖Product产品类和User用户类是由其他人写的

问题：

1. Product产品类和User用户类一旦出现情况不至于让你误以为是Cart类的代码出了问题.
2. 不用为了创造很多前置条件,才能做出断言.(如果这样应该放在集成测试)
3. 在测试购物车时,我们应该避免使用"new Cart($userUid, $productId, $quantity)"这种方式,
如果程序中都是id去查询,这样会影响执行效率,和不利于打桩,
我们应该使用这种"new Cart(User $user, Product $product, $quantity)"方式.