您在哪里嘲笑-直接依赖，还是扩大界限…？

Question

因此，我对于C＃和.NET中的单元测试和模拟都是相当陌生的；我分别使用xUnit.net和Rhino Mocks。我是一名转换者，我想我将重点放在编写行为规范上，而不是纯粹是TDD。 ah，语义；我本质上希望自动化安全网在上面工作。

一个念头虽然打动了我。我可以根据接口进行编程，而将依赖项分解的好处就在那里。卖了但是，在我的行为验证套件（也称为单元测试;-)）中，我一次声明一个接口的行为。就像在其中一样，一次实现一个接口，并模拟所有接口的依赖关系并建立期望。

这种方法似乎是，如果我们验证一个类对它的协作依赖项表现出应有的表现，并反过来依靠这些协作依赖项中的每一个都签署了相同的质量合同，那么我们就很成功了。似乎足够合理。

不过，回到思想上来。半集成测试中是否有任何价值？在这种测试中，测试夹具针对连接在一起的具体实现单元进行断言，而我们正在针对模拟的依赖项测试其内部行为？我重新阅读了一下，我想我可能会措辞更好。显然，我想会有一定程度的“嗯，如果它能为您增加价值，那就继续做下去”-但是还有其他人考虑过这样做，并且从中获得的收益超过了成本吗？

Answer 1

您的问题已经辩论了多年，也可以改为“什么是单位”？

没有单元测试法则要求您单独测试每个类。但是，为了保持可维护性，您真正想要的测试仅在测试行为改变时才需要更改。以这种方式看待它，通常合理的做法是使用紧密协作者的具体版本，而对于较远的协作者则使用伪造品。

我绝对使用一种或另一种假货的地方是遵循迈克尔·费瑟（Michael Feather）的单元测试规则。

Answer 2

我看不到仅将完全可单元测试的内部类链接在一起的集成测试的价值。

在我看来，集成测试的价值在于它与平台或外部接口的联系，即您无法进行单元测试的合同。