Question

我通过方法链创建了一些小的流畅接口。它们通常调用许多从Web服务/数据库中获取数据的存储库。

我应该如何处理使用流畅界面的单元测试方法？

Public IEnumberable<Computer> FindComputers(string serialNumber)
{
      return Computers.FindBySerialNumber("YBCX00900")
         .AttachConfiguration()
         .EnsureAllComputersHaveConfiguration();
}

我可以对流畅界面的各个组件进行单元测试，但如果我想对上面的FindComputers方法进行单元测试，我该怎么办？

使用流畅的界面的具体实现，并写对存储库类的期望
模仿流畅的界面本身并设定期望
仅测试流畅的界面本身，而不测试FindComputers（）方法

我想找到一种易于维护的方法。

Answer 1

我认为FI正在做的不仅仅是它需要的。我假设您使用计算机作为数据映射器，并使用它来构建查询。根据您显示的内容，查询构建于此：

rule 1: find configured computer with serial number = "whatever" and has-config = true.
rule 2: find not-config computer with serial number = "whatever and has-config = true.
rule 3: find configured computer with serial number = "whatever" and has-config = false.
rule 4: find not-config computer with serial number = "whatever" and has-config = false.
rule 5: find all computer with serial number = "whatever" and has-config = true.
rule 6: find all computer with serial number = "whatever" and has-config = false.

依旧......

现在，其中一些可以实施的规则似乎不正确。规则2和规则3似乎是交叉目的。规则5和规则6做了什么？这是对的吗？

因为您已经实现了一个破坏SRP的对象。第一步是从数据映射器中断查询构建器。构建FI查询对象，然后将其传递给映射器。

现在，您可以测试 FindComputers ，确保将FI查询对象发送到数据映射器。因为您现在可以构建FI查询对象，所以可以对其进行测试。您可以测试数据映射器是否使用查询对象。

如果您希望将来按位置查找计算机，该怎么办？如果您保留与您编写的代码相同的代码，则必须添加方法 FindByLocation ，在您知道它之前，您有一个神对象。臭！

Answer 2

你能嘲笑你的存储库吗？虽然有些人会主张更纯粹的方法，你必须隔离一个类的一个方法，但测试FindComputers和流畅的接口如何协同工作将是一个不错的方法。它可能更简单，具体取决于存储库访问层的外观。

Answer 3

我会做2 + 3。假设流畅的接口是真正的接口，它们应该相对简单地模拟。只是意识到调用链中的每一步都应该返回一个新的模拟对象，这反过来又期望链中的下一个调用。

你仍然应该直接测试流畅的界面，模仿它们下面的存储库层。

如何对使用Fluent界面的代码进行单元测试？

3 个答案: