0

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

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

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

所以，我让 MVC 将我的 RestClient 注入到我的管理器类中。我让 MVC 注入器设置基本 url。所有这些我都可以接受，但我有以下问题：

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

我倾向于第四个项目符号，因为它涉及到正在测试的实际解决方案？

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

4

2 回答 2

1

在与朋友讨论后，我决定使用具体实现。

原因是这个对象实际上只是一个 POCO，没有必要将其抽象出来（即使提供了抽象）。这是我的服务调用者的具体实现，因此正在测试的实际解决方案是调用。不过，我可能会对此进行模拟并验证是否按照应有的方式调用了重新请求。

但是，我们想出的简短答案是 POCO 不需要被抽象掉。

于 2012-02-29T00:35:07.520 回答
1

我很清楚这个困境；并且来过这里几次。

归根结底，您可以抽象所有内容，但最终会得到毫无意义的测试，并且您会发现自己正在编写无关紧要的测试框架，或者实际上是在绕过公认的框架规范以寻找“一个”真正的测试方法”。实际上，我一直在对话中，人们真诚地讨论过传递抽象接口，你只需要输入一个整数。

在写这篇文章时，我看到了你自己的答案；我完全同意。

只要您可以验证假设并测试行为，那么您就做得足够了；就像你说的那样——你只需要检查事情是否发生了变化，并且你自己知道你自己上下文的界限——提供者真的会改变吗？不 - 不要抽象它。

最近，我为我的雇主设计了一些大型 Microsoft Dynamics CRM 解决方案；最终我的测试假设 CRM API 是好的，他们只是测试我的包装器的行为。

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

于 2012-02-29T00:41:56.033 回答