c# - 在测试中使用模拟

Question

我最近才开始在我的测试中使用模拟对象(使用 Java 的 mockito)。不用说，他们简化了测试的设置部分，并且与依赖注入(inject)一起，我认为它使代码更加健壮。

但是，我发现自己在针对实现而不是规范进行测试时遇到了麻烦。我最终设定了我认为这不是测试的一部分的期望。用更专业的术语来说，我将测试 SUT(被测类)与其协作者之间的交互，这种依赖不是契约的一部分，也不是类的接口(interface)!

假设您有以下内容:在处理 XML 节点时，假设您有一个方法 attributeWithDefault()，如果可用则返回节点的属性值，否则返回默认值!

我会像下面这样设置测试:

Element e = mock(Element.class);

when(e.getAttribute("attribute")).thenReturn("what");
when(e.getAttribute("other")).thenReturn(null);

assertEquals(attributeWithDefault(e, "attribute", "default"), "what");
assertEquals(attributeWithDefault(e, "other", "default"), "default");

好吧，这里我不仅测试了 attributeWithDefault() 是否符合规范，而且我还测试了实现，因为我要求它使用 Element.getAttribute()，而不是 Element.getAttributeNode().getValue() 或 Element.getAttributes().getNamedItem().getNodeValue() 等

我假设我正在以错误的方式处理它，因此任何关于我如何改进模拟使用和最佳实践的提示将不胜感激。

编辑:测试有什么问题

我在上面假设测试是一种糟糕的风格，这是我的理由。

1. 规范没有指定调用哪个方法。例如，只要正确完成，库的客户端不应该关心如何检索属性。实现者应该可以自由地访问任何替代方法，以他认为合适的任何方式(关于性能、一致性等)。 Element 的规范确保所有这些方法返回相同的值。

2. 用 getElement() 将 Element 重构为单个方法接口(interface)是没有意义的(实际上 Go 在这方面做得很好)。为了便于使用，该方法的客户端应该能够只使用标准库中的标准 Element。拥有接口(interface)和新类简直是愚蠢，恕我直言，因为它使客户端代码变得丑陋，而且不值得。

3. 假设规范保持原样并且测试保持原样，新开发人员可能决定重构代码以使用不同的状态使用方法，并导致测试失败!好吧，当实际实现符合规范时，测试失败是有效的。

4. 让协作者以多种格式公开状态是很常见的。规范和测试不应依赖于采用哪种特定方法；只有实现应该!

Answer 1

这是模拟测试中的常见问题，避免这种情况的一般口头禅是:

Only mock types you own.

在这里，如果你想模拟与 XML 解析器的协作(老实说，不一定需要，因为一个小的测试 XML 应该在单元上下文中工作得很好)那么 XML 解析器应该在你拥有的接口(interface)或类后面将处理您需要调用第三方 API 上的哪个方法的困惑细节。要点是它有一个从元素获取属性的方法。模拟那个方法。这将实现与设计分开。真正的实现将有一个真正的单元测试，它实际测试你从一个真实的对象中获得一个成功的元素。

模拟可能是保存样板设置代码(本质上充当 stub )的好方法，但这不是它们在驱动设计方面的核心目的。模拟正在测试行为(与状态相反)并且是 not Stubs .

我应该补充一点，当您将 Mock 用作 stub 时，它们看起来就像您的代码。任何 stub 都必须假设您将如何调用它，这些假设与您的实现相关联。那是正常的。问题在于它是否以错误的方式驱动您的设计。