如果我测试服务包装器，我应该抽象一切吗？

Question

我有一个服务管理器类，用于将我的调用从我的MVC项目抽象到我的REST服务。 所有管理器类都设置了Rest调用（使用RestSharp）并将服务数据返回给MVC应用程序。

所以，起初我认为不测试这样一个微不足道的类，但已经决定测试将防止未来可能更复杂的变化。

然而，这是我的困境。我应该在多远的时间内抽象出来以便我可以单独测试？

所以，我正在将我的RestClient注入MVC​​到我的经理类中。我让MVC注入器设置基本URL。 所有这一切我都很好，但这里有我的问题：

• 对于我的方法调用，我应该让我的方法接受参数（userId）和IRestRequest吗？
  • 我的问题是，我的通用服务管理器突然变为Rest特定，因为我的界面需要包含这两个参数。
• 如果我没有将IRestRequest注入到方法中并让实现创建它，这是否正确，因为这将被忽略，因为正在测试的主要方法是RestClient.Execute，它将被删除而不关心实际的RestRequest？
  • 事实上，由于这是实现的一部分，我可以模拟并验证是否在相应的RestRequest对象中发送了Execute方法？
• 或者，我应该不注入IRestRequest，而是将IRequestResolver注入我的构造函数中？然后在我的方法调用中，我可以使用IRequestResolver，它将接受表示该方法的字符串。然后，这将用于计算RestRequest参数并返回为方法适当填充的RestRequest对象？
• 或者，我应该只是在我的第一个子弹下执行子弹，并使用具体实现。
• 我缺少的其他选项？

我倾向于第四个子弹，因为它到达了正在测试的实际解决方案？

如果您需要更多细节来帮助我解决困境，请告诉我。

Answer 1

在和朋友讨论之后，我决定继续使用具体实现。

原因是这个对象实际上只是一个POCO，并且没有必要将其抽象出来（即使提供了抽象）。这是我的服务调用者的具体实现，因此正在测试的实际解决方案是调用。我可能会嘲笑这个，并验证restrequest是否应该以它应该的方式被调用。

但是，我们提出的简短回答是，POCO不需要被抽象出来。

Answer 2

我很清楚这种困境;并且已经来过几次。

当涉及到它时，你可以抽象出所有内容，但是你最终会进行无意义的测试，并且你发现你正在编写无关紧要的测试框架，或者你实际上绕过了公认的框架规范来寻找'一种真正的测试方法'。我实际上在谈话中，人们老老实实地讨论了传递抽象接口，你只需要输入一个整数。

写这篇文章的时候，我已经看到了你自己的答案;我完全同意。

只要您能够验证假设和测试行为，那么您就做得足够;就像你说的那样 - 你只需要检查事情是否发生了变化，你自己就知道自己背景的界限了 - 提供者是否真的会改变？不 - 不抽象它。

最近，我为我的雇主构建了一些大规模的Microsoft Dynamics CRM解决方案;最终我的测试假设CRM API没问题，他们只是测试我的包装器的行为。

无论如何，这只是我看到的球场，我希望这对你有一定价值！