tdd - BD/TDD : can dependencies be a behavior?

Question

我被告知不要使用实现细节。依赖关系看起来像是一个实现细节。不过我也可以将其表述为一种行为。

示例:LinkList 依赖于存储引擎来存储其链接(例如 LinkStorageInterface)。构造函数需要传递一个已实现的 LinkStorageInterface 的实例才能完成其工作。 我不能说“shouldUseLinkStorage”。但也许我可以说“shouldStoreLinksInStorage”。

在这种情况下，“测试”正确的是什么？我应该测试它是否在商店中存储链接(行为)还是根本不测试它？

Answer 1

依赖关系本身不是预期的行为，但对依赖关系调用的操作肯定是预期的行为。您应该测试您(调用者)了解的内容，并避免测试需要您深入了解 SUT 内部工作原理的内容。

稍微扩展一下您的示例，假设我们的 LinkStorageInterface 具有以下定义(伪代码):

Interface LinkStorageInterface

  void WriteListToPersistentMedium(LinkList list)

End Interface

现在，由于您(调用者)正在为该接口(interface)提供具体实现，因此您可以完全合理地测试在调用 Save() 时调用 WriteListToPersistentMedium() LinkList 上的 方法。

测试可能如下所示，再次使用伪代码:

void ShouldSaveLinkListToPersistentMedium()

  define da = new MockLinkListStorage()  
  define list = new LinkList(da)

  list.Save()

  Assert.Method(da.WriteListToPersistentMedium).WasCalledWith(list)

end method

您已经测试了预期的行为，但没有测试 SUT 或模拟的实现特定细节。您希望(主要)避免测试的是:

1. 调用方法的顺序
2. 公开方法或属性，以便您可以检查
3. 任何不直接涉及您正在测试的预期行为的内容

同样，依赖项是您作为类的使用者所提供的东西，因此您希望使用它。否则，一开始就有这种依赖是没有意义的。