我被告知不要使用实施细节。依赖关系看起来像是一个实现细节。但我也可以将其表述为一种行为。
示例：LinkList 依赖于存储引擎来存储其链接（例如 LinkStorageInterface）。构造函数需要传递一个已实现的 LinkStorageInterface 的实例才能完成其工作。
我不能说“shouldUseLinkStorage”。但也许我可以说“shouldStoreLinksInStorage”。
在这种情况下，什么是正确的“测试”？我应该测试它是否在商店中存储链接（行为）还是根本不测试它？
依赖关系本身不是预期的行为，但对依赖关系调用的操作肯定是预期的行为。您应该测试您（调用者）了解的内容，并避免测试需要您深入了解 SUT 内部工作原理的内容。
稍微扩展一下您的示例，假设我们的 LinkStorageInterface 具有以下定义（伪代码）：
Interface LinkStorageInterface
void WriteListToPersistentMedium(LinkList list)
End Interface
现在，由于您（调用者）正在提供该接口的具体实现，因此您测试该接口是完全合理的WriteListToPersistentMedium()当您调用时被调用Save()方法对你的LinkList.
测试可能如下所示，再次使用伪代码：
void ShouldSaveLinkListToPersistentMedium()
define da = new MockLinkListStorage()
define list = new LinkList(da)
list.Save()
Assert.Method(da.WriteListToPersistentMedium).WasCalledWith(list)
end method
您已经测试了预期的行为，但没有测试 SUT 或模拟的实现特定细节。你想要避免测试的（大部分）是这样的：
- 方法调用的顺序
- 公开一个方法或属性，以便您可以检查它
- 任何不直接涉及您正在测试的预期行为的内容
同样，依赖项是您作为类的使用者所提供的东西，因此您希望使用它。否则，一开始就有这种依赖是没有意义的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
