带有副作用的单元测试方法

据我所知“单元测试不应该测试内部实现细节以便不会使该方法的重构复杂化”。那么，我该如何测试这种方法呢？带有副作用的单元测试方法

deleteOrder = (order) -> 
    backendService('deleteOrder', order.id) 
    cacheOfOrders.delete(order)

从我的单元测试环境（茉莉花），我可以打电话deleteOrder和模拟后端电话，但我不能访问到cacheOfOrders。我想检查一下cacheOfOrders.length是否缩小了。也许我做错了，我不应该测试内部细节，但是如果我有一个像前一个方法但没有后端调用的方法呢？

来源

2015-02-24 Enrique Marcos

你可以创建一个'cachOfOrders'对象作为一个单独的测试，你可以运行吗？ – gmiley 2015-02-24 19:52:14

cacheOfOrders对于有问题的服务是私有的。我无法访问或参考它。 – 2015-02-24 19:58:07

我的意思是，什么是cacheOfOrders的一个实例？你可以测试该类的新实例，而不是通过实际实现它的内部工作来测试它吗？如果它是开发人员创建的自定义类，则应该对其进行测试。如果它是框架提供的标准类，则不需要打扰它。 – gmiley 2015-02-25 12:15:58

灵活的解决方案可以让你的缓存成为一个可注入的参数，不管你在这里做什么，所以你可以传递一个模拟缓存对象，然后你可以测试。

除此之外，您是否有一种方法可以用来从缓存中查找订单？您可以断言在您拨打deleteOrder后，缓存不会返回有效的条目。如果您的查找在缓存中存在项目时避免了后端服务调用，那么您可以进行测试以确保在删除之后，查找调用确实会触发后端服务（这意味着缓存未被填充）。也就是说，测试缓存正常运行的效果，而不是测试缓存本身。

来源

2015-02-24 19:58:49

我没有写这个方法，我是“单元测试团队”（呃）的一部分。缓存不可访问，它没有任何公共接口......我开始认为缓存是一个非常内部的细节。 – 2015-02-24 20:16:55

带有副作用的单元测试方法

回答

相关问题