我对模拟和伪造对象有基本的了解，但是我不确定我对何时/何处使用模拟有一种感觉-尤其是在这里适用于这种情况。
当您要测试被测类和特定接口之间的交互时，模拟对象很有用。
好。
例如，我们要测试方法sendInvitations(MailServer mailServer)完全调用一次MailServer.createMessage()，并且也恰好调用一次MailServer.sendMessage(m)，并且在MailServer接口上没有调用其他方法。这是我们可以使用模拟对象的时候。
好。
使用模拟对象，而不是传递真实的MailServerImpl或测试TestMailServer，我们可以传递MailServer接口的模拟实现。在传递模拟MailServer之前，我们对其进行"训练"，以使它知道期望调用的方法以及要返回的返回值。最后，模拟对象断言，所有预期的方法均按预期方式调用。
好。
从理论上讲，这听起来不错，但也有一些缺点。
好。
模拟缺点
如果您有一个模拟框架，那么每次需要将接口传递给被测类时，您都倾向于使用模拟对象。这样，即使没有必要，您也可以测试交互。不幸的是，不需要的(偶然的)交互测试是不好的，因为然后您正在测试以特定的方式实现了特定的需求，而不是实现产生了所需的结果。
好。
这是伪代码示例。假设我们已经创建了一个MySorter类，并且要对其进行测试：
好。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| // the correct way of testing
testSort() {
testList = [1, 7, 3, 8, 2]
MySorter.sort(testList)
assert testList equals [1, 2, 3, 7, 8]
}
// incorrect, testing implementation
testSort() {
testList = [1, 7, 3, 8, 2]
MySorter.sort(testList)
assert that compare(1, 2) was called once
assert that compare(1, 3) was not called
assert that compare(2, 3) was called once
....
} |
(在此示例中，我们假设它不是要测试的特定排序算法，例如快速排序；在这种情况下，后者测试实际上是有效的。)
好。
在这样一个极端的例子中，很明显为什么后一个例子是错误的。当我们更改MySorter的实现时，第一个测试在确保我们仍然正确排序方面做得很好，这就是测试的重点-它们使我们能够安全地更改代码。另一方面，后一种测试总是会中断，并且是有害的。它阻碍了重构。
好。
嘲弄存根
模拟框架通常也允许不太严格的用法，在这种情况下，我们不必确切指定应调用方法的次数和期望的参数。它们允许创建用作存根的模拟对象。
好。
假设我们有一个要测试的方法sendInvitations(PdfFormatter pdfFormatter, MailServer mailServer)。 PdfFormatter对象可用于创建邀请。这是测试：
好。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| testInvitations() {
// train as stub
pdfFormatter = create mock of PdfFormatter
let pdfFormatter.getCanvasWidth() returns 100
let pdfFormatter.getCanvasHeight() returns 300
let pdfFormatter.addText(x, y, text) returns true
let pdfFormatter.drawLine(line) does nothing
// train as mock
mailServer = create mock of MailServer
expect mailServer.sendMail() called exactly once
// do the test
sendInvitations(pdfFormatter, mailServer)
assert that all pdfFormatter expectations are met
assert that all mailServer expectations are met
} |
在此示例中，我们并不真正在意PdfFormatter对象，因此我们只是训练它静默地接受任何调用并为sendInvitation()恰好在此时调用的所有方法返回一些合理的固定返回值。我们是如何精确地得出此训练方法清单的？我们只运行测试并不断添加方法，直到测试通过。注意，我们训练了存根以对方法做出响应，而又不知道为什么需要调用它，我们只是添加了测试所抱怨的所有内容。我们很高兴，测试通过了。
好。
但是，当我们更改sendInvitations()或sendInvitations()使用的其他类以创建更多精美的pdf时，会发生什么呢？我们的测试突然失败了，因为现在调用了PdfFormatter的更多方法，并且我们没有训练存根来期望它们。通常，不仅是在这种情况下失败的测试，而且是直接或间接使用sendInvitations()方法的任何测试。我们必须通过增加培训来修复所有这些测试。还要注意，我们无法删除不再需要的方法，因为我们不知道不需要哪些方法。同样，它阻碍了重构。
好。
而且，测试的可读性非常糟糕，因为有我们想要的代码，所以我们没有编写很多代码，但是因为我们不得不这样做。不是我们想要在那里的代码。使用模拟对象的测试看起来非常复杂，通常很难阅读。测试应该帮助读者理解，应该如何使用测试中的类，因此它们应该简单明了。如果它们不可读，那么没人会去维护它们。实际上，删除它们比维护它们容易。
好。
如何解决？容易：
好。
尽可能尝试使用实型而不是模拟。使用真实的PdfFormatterImpl。如果不可能，请更改实际类以使其成为可能。无法在测试中使用类通常会指出该类的一些问题。解决问题是一种双赢的局面-您修复了类，并且进行了更简单的测试。另一方面，不修复它并使用模拟程序是双赢的情况-您没有修复真实的类，并且您拥有更复杂，可读性更差的测试，从而阻碍了进一步的重构。
尝试为接口创建一个简单的测试实现，而不是在每个测试中对其进行模拟，并在所有测试中使用此测试类。创建不执行任何操作的TestPdfFormatter。这样一来，您可以为所有测试更改一次，并且您的培训不会因冗长的设置而杂乱无章。
好。
总而言之，模拟对象有其用途，但如果使用不当，它们通常会鼓励不良做法，测试实现细节，阻碍重构并产生难以阅读和难以维护的测试。
好。
有关模拟缺点的更多详细信息，另请参见模拟对象：缺点和用例。
好。
好。
单元测试应通过单一方法测试单一代码路径。当一个方法的执行从该方法的外部传递到另一个对象，然后又返回时，您就具有了依赖性。
当您使用实际的依赖关系测试该代码路径时，就不是单元测试；您正在进行集成测试。尽管这是很好且必要的，但这不是单元测试。
如果您的依赖项存在错误，则可能会以返回假阳性的方式影响您的测试。例如，您可能将依赖项传递给意外的null，并且依赖项可能不会像记录中所述那样抛出null。您的测试不会发出应有的空参数异常，并且测试通过。
此外，您可能会发现，即使不是不可能，也很难可靠地使相关对象返回测试期间想要的值。这还包括在测试中引发预期的异常。
模拟代替了该依赖关系。您可以设置对依赖对象的调用的期望值，设置应该给您的确切返回值，以执行所需的测试，和/或抛出什么异常，以便可以测试异常处理代码。这样，您可以轻松测试所涉及的单元。
TL; DR：模拟单元测试所涉及的每个依赖项。
经验法则：
如果要测试的函数需要一个复杂的对象作为参数，并且简单地实例化该对象(例如，如果它尝试建立TCP连接)将很痛苦，请使用模拟。
当您尝试测试的代码单元中具有依赖性时，应该模拟一个对象，该对象必须"正好如此"。
例如，当您尝试在代码单元中测试某些逻辑但您需要从另一个对象获取某些东西时，从此依赖项返回的内容可能会影响您要测试的内容-模拟该对象。
可以在这里找到有关该主题的出色播客
