使用方法内部的静态调用设计Java单元测试

Question

我正在尝试为一个类创建单元测试，该类的方法使用apache的fluent-hc库中的Request.Post方法（ http://hc.apache.org/httpcomponents-client-ga/fluent-hc/apidocs /org/apache/http/client/fluent/Request.html ）。

问题是我不希望每次运行测试服时都发送实际的请求，即使是单元测试而不是集成测试也是如此。 但是我不知道该如何解决。

我是测试领域的新手，对于大多数时间我无法阅读的内容，该类的设计存在问题。

public class HttpRequestSenderServiceImpl implements RequestSenderService {

@Override
public Response sendRequest(String address, String messageBody) throws IOException {
    Request request = Request.Post(address).bodyString(messageBody, ContentType.APPLICATION_JSON);
    Response response = request.execute();

    return response;
}

}

我正在使用Spring框架和Spring-Test，Mockito和TestNG作为测试工具。 如果您至少能指出正确的方向，阅读的任何材料，书籍，视频或其他任何内容，我将不胜感激。 我只想学习正确的方法。

我找到了解决问题的“解决方案”，但是它们都使用PowerMockito，因为我阅读的内容对您不利，因为允许模拟静态方法，构造函数等，这会转化为不良的编码做法，这就是我的意思。我试图避免在这里。

Answer 1

为了您的目的，问题更多是在Apache的fluent-hc Request.Post ，而不是代码友好，它是静态的，不是模拟友好的。

您可以使用Executor和模拟执行方法，也可以使用Request.Post将其包装在另一个低层服务接口中并使用它：

interface RequestSender {
      Response send(String addr,msgBody)
}

class RequestSenderImpl implements RequestSender {
    public Response send(String addr,msgBody) {
       Request request = Request.Post(address).bodyString(messageBody,ContentType.APPLICATION_JSON);
       Response response = request.execute();
       return response;
    }
}

这样一来，即使没有模拟，您也可以轻松模拟代码。

Answer 2

@lujop针对上述问题提供了建议，我认为这是解决问题的一种方法。

但是，对于之前使用模拟框架的声明，我不是一直都是完全不好的做法。 考虑@lujop的建议，您可能最终会使用Test Double来对RequestSenderImpl及其业务逻辑进行单元测试。

但是会有一个类，例如FluentHCRequestSender ，它将负责实际调用Request.Post 。 现在，如果您要为所有类编写UT，则必须使用FluentHCRequestSender框架来测试FluentHCRequestSender以确保该类使用了正确的API。

有一个使用模拟框架进行测试的地方。 但是总的来说，如果依赖项是您，您的团队或组织创建的类，而最终使用了模拟框架，那就说明设计不好。

为了回答您的资源问题，这些资源通常可以帮助您编写更好的UT和代码，

SOLID原则 -在编写代码时，这可能永远是我的脑海。

有效地使用旧版代码对我很有帮助。

测试驱动的开发 -在我的练习中，要严格遵循日常工作并非易事，但这至少迫使我不要推迟UT并与我的实际课程同时进行（如果不是之前） 。

设计模式 -如果您可以访问或购买图书馆，则可以抓住一本好的设计模式书/视频。 这些概念看似令人生畏，但我发现其中一些确实对我的日常工作特别是在编写UT时有用。

但就个人而言，这是学习在代码库中查看现有代码并了解有什么好处和可以改进的最好方法。 我发现寻找和理解由擅长设计的人编写的代码比任何书籍都有用。

希望这篇冗长的帖子对您​​有所帮助！

PS-尝试正确方法的荣誉。 有时它不是应该经常说，尽管应该这样。