Java：如何对封装的注入或生成的依赖项进行单元测试？

Question

SUMMARY: I have a self-contained class for performing a proxied login and then filling a HttpServletResponse object with authentication content a browser can use. When testing my code, how can I provide mocked services into a class that has no setters?

DETAILS: I've severely edited my proxied login code into this snippet.

1. It asks the server for a login form.
2. It sends back the credentials.
3. It gets the server's approval and passes it to the browser (response).

The trimmed code looks like this:

    private static final Log log = LogFactory.getLog(MyClass.class);

    @Inject()
    private UserService userService;

    public void performProxyLogin(HttpServletResponse response, 
            UserDTO userDTO, String url) {

        String username = getUsername(userDTO);
        String password = getPasswordFromUserService(username);

        // MyRequest only has data, organizing a Http Request.
        MyRequest myRequest = prepareInitialGetRequest(url);  

        // processURLRequest() encapsulates use of HttpURLConnection.
        // MyResponse only has data, organizing a Http Response.
        MyResponse myResponse = processURLRequest(myRequest); 
        myRequest = prepareLoginRequest(myResponse, username, password);
        myResponse = processURLRequest(myRequest);

        // Transfer data into the response, and from there into the browser.
        fillResponseWithProxiedResult(response, myResponse)
    }

To make this work I think I need to inject a mocked Log or LogFactory, a mocked UserService, and a way of getting a mocked HttpURLConnection.

However, all of the advice I've seen involves code with setters, which the test suite can use to plug in mocked objects.

How do I provide my class its needed mocked objects?

Answer 1

Bite the bullet and provide a package-private setter for this field.

If you want to use mocks, there's no value in letting the injection framework set up a mock which you can inject, since you're adding more ceremony and overhead to the set-up of your test.

If you want to validate that you have a service injecting correctly, you wouldn't want to use mocks at all (think "integration test" with real or pseudo-real components).

Answer 2

Many of the other answers hint at it, but I'm going to more explicitly say that yes, naive implementations of dependency injection can break encapsulation. The key to avoiding this is that calling code should not directly instantiate the dependencies (if it doesn't care about them). This can be done in a number of ways. The simplest is simply have a default constructor that does the injecting with default values. As long as calling code is only using the default constructor you can change the dependencies behind the scenes without affecting calling code. This can start to get out of hand if your dependencies themselves have dependencies and so forth. At that point the Factory pattern could come into place (or you can use it from the get-go so that calling code is already using the factory). If you introduce the factory and don't want to break existing users of your code, you could always just call into the factory from your default constructor. Beyond that there's using Inversion of Control. I haven't used IoC enough to speak too much about it, but there's plenty of questions here on it as well as articles online that explain it much better than I could. If it should be truly encapsulated to where calling code cannot know about the dependencies then there's the option of either making the injecting (either the constructor with the dependency parameters or the setters) internal if the language supports it, or making them private and have your unit tests use something like Reflection if your language supports it. If you language supports neither then I suppose a possibility might be to have the class that calling code is instantiating a dummy class that just encapsulates the class the does the real work (I believe this is the Facade pattern, but I never remember the names correctly)]