我应该如何使用大量 DOC（依赖代码）对方法进行单元测试？答案

【问题标题】：How should I unit test methods with lots of DOC's (depended-on code)?我应该如何使用大量 DOC（依赖代码）对方法进行单元测试？
【发布时间】：2010-11-17 03:16:40
【问题描述】：

假设我们有一个方法主要将各种其他方法连接在一起；没有做很多自己的逻辑。假设它是服务层中服务类的典型成员，调用领域模型（业务）类、数据访问类和电子邮件实用程序/服务类中的方法。

我发现为这种方法编写一个真正的单元测试需要大量的测试双重设置，而且这里测试的逻辑很少。如果我继续这样下去，似乎成本会超过价值。我该怎么办？

【问题讨论】：

一个单元测试的例子也会很有帮助。

标签： unit-testing mocking

【解决方案1】：

每个单元测试不应超过一个模拟。来自 Roy Osherove 的单元测试的艺术（第 94 页）：

在你只测试一个的测试中事情（这就是我推荐你的方式写测试），应该没有更多比一个模拟对象。其他都是假的对象将充当存根。拥有更多比每个测试一个模拟通常意味着你在测试不止一件事，这可能导致复杂或脆性测试。

Here 是一个相关的堆栈溢出问题，可能会有所帮助。

【讨论】：

抱歉，我使用的是一般意义上的“模拟”一词——即，Test Double（使用 xUnit 测试模式术语）。我会相应地进行编辑。
但你仍然提出了一个我从未想过的好观点，所以 +1。

【解决方案2】：

在单元测试方面，我不是一个纯粹主义者。有一个收益递减点，即创建和维护给定测试的成本可能大于执行该测试所获得的收益。但是，对于该点的存在位置并没有硬性规定。

我选择为与您描述的代码类似的代码编写单元测试。但是，在大多数情况下，我确保底层对象（您将要模拟的对象）具有针对它们运行的适当单元测试。但是，在存在大量内部逻辑的情况下，单元测试绝对是当务之急。

我认为这个问题没有正确答案，但希望下面我的 cmets 有助于您思考如何以及是否应该对此进行单元测试。

【讨论】：