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 回答