BDD/TDD：依赖可以是一种行为吗？

Question

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

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

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

Answer 1

LinkStorageInterface 不是一个实现细节——它的名字暗示了一个引擎的接口。 在这种情况下，名称 shouldUseLinkStorage 比 shouldStoreLinksInStorage 更有价值。

这就是我的2便士的价值！

Answer 2

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

稍微扩展一下您的示例，让我们想象一下我们的 LinkStorageInterface 具有以下定义（伪代码）：

Interface LinkStorageInterface

  void WriteListToPersistentMedium(LinkList list)

End Interface

现在，由于您（调用者）正在提供该接口的具体实现，因此您测试 WriteListToPercientMedium 是完全合理的当您在 LinkList 上调用 Save() 方法时，() 就会被调用。

测试可能看起来像这样，再次使用伪代码：

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. 任何不直接涉及您正在测试的预期行为的东西

再次强调，依赖关系是一种东西您作为该类的使用者所提供的，因此您希望它被使用。 否则，一开始就有这种依赖是没有意义的。