我正在学习单元测试，并努力学习一些可能相当基本的概念。假设我有两种方法。
方法A将文件作为输入并返回复杂的对象层次结构。
方法B采用对象层次结构并对其执行某些操作。
我理解如何测试方法A（以及它依次调用的各种其他方法）。我对如何最好地测试方法B感到困惑。
我可以在我的单元测试中建立一个假对象层次结构作为方法B的输入但是当我这样做时，感觉就像我的单元测试已经不再是对方法B的测试而是更多的测试我是否正确地手动创建了一个有效的对象层。
对我来说，测试方法A，保持输出然后用它来测试方法B似乎更合乎逻辑但我知道每个单元测试只是为了测试一件事。
我（想）我理解嘲讽和伪造的概念，但我不确定这是答案，因为方法B将使用整个对象层次结构而不只是看它的一小部分。
答案 0 :(得分：5)
严格的单元测试可以单独测试。因此，如果是单元测试，您应该单独测试。您还可以使用集成测试来测试methodA和methodB。我个人会从基本单元测试开始，单独测试，特别是如果methodB是非平凡的或任务关键的。当您单独进行测试时，可以降低测试本身的某些内容导致通过的可能性，此时隔离测试会显示失败。
有些情况下单独测试是不切实际的。还有一些情况，两种方法都是如此微不足道，我会一起测试它们，比如setter / getters。然而，这似乎不是其中之一，因为您主要是抱怨创建测试数据。
为了减轻单元测试数据创建的痛苦，我经常使用静态（在Java-land中）方法构建一个TestUtil类，它返回测试数据，然后我测试TestUtil < / em>的。这样我只能通过做一次乏味的物体建设的痛苦，我相信它是正确的。在您的情况下，由于您已经测试了文件生成代码，我将获取其输出并将其放入其中一个实用程序方法中，然后使用实用程序方法单独测试methodB。
最后，如果methodB接受一个复杂的输入，并且它对整个输入起作用，并且它很复杂，那么可能是methodB本身太复杂，应该分解为更小，更易于管理和可测试的方法。
单元/集成测试的主要好处之一是它可以通知应用程序设计。如果难以测试，那可能太复杂了......
编辑 - 从你的澄清，听起来像方法B是相当复杂的。绝对测试B单独调用的方法;我不会这样做的唯一一次是所有的方法都是私有的，不能孤立地进行测试。