Как я тестирую инжекции Guice?

Для любого сложного проекта Guice вы должны добавить тесты, чтобы убедиться, что модули можно использовать для создания ваших классов. В вашем примере, если B был типом, который Guice не мог понять, как создать, тогда Guice не сможет создать A. Если A не требовался для запуска сервера, но был необходим, когда ваш сервер обрабатывал запрос, который вызовет проблемы.

В своих проектах я пишу тесты для нетривиальных модулей. Для каждого модуля я использую requireBinding () , чтобы объявить, какие привязки модуль требует, но не определяет. В своих тестах я создаю инжектор Guice, используя тестируемый модуль и другой модуль, который предоставляет необходимые привязки.Вот пример использования JUnit4 и JMock:

/** Module that provides LoginService */
public class LoginServiceModule extends AbstractModule {
  @Override 
  protected void configure() {
    requireBinding(UserDao.class);
  }

  @Provides
  LoginService provideLoginService(UserDao dao) {
    ...
  }
}

@RunWith(JMock.class)
public class LoginServiceModuleTest {
  private final Mockery context = new Mockery();

  @Test
  public void testModule() {
    Injector injector = Guice.createInjector(
        new LoginServiceModule(), new ModuleDeps());

    // next line will throw an exception if dependencies missing
    injector.getProvider(LoginService.class);
  }

  private class ModuleDeps extends AbstractModule {
    private final UserDao fakeUserDao;

    public ModuleDeps() {
      fakeUserDao = context.mock(UserDao.class);
    }

    @Override 
    protected void configure() {}

    @Provides
    Server provideUserDao() {
      return fakeUserDao;
    }
  }
}

Обратите внимание, что тест запрашивает только поставщика. Этого достаточно, чтобы определить, что Guice может разрешить привязки. Если LoginService был создан методом поставщика, этот тест не будет проверять код в методе поставщика.

Этот тест также не проверяет, правильно ли вы связали UserDao или что область UserDao была правильно определена. Некоторые утверждают, что такие вещи редко стоит проверять; если есть проблема, это случается один раз. Вы должны «тестировать, пока страх не превратится в скуку»

. Я считаю, что модульные тесты полезны, потому что я часто добавляю новые точки внедрения, и легко забыть добавить привязку.

Вызовы requireBinding () могут помочь Guice обнаружить недостающие привязки до того, как он вернет ваш инжектор! В приведенном выше примере тест все равно работал бы, если бы не было вызовов requireBinding () , но мне нравится их наличие, потому что они служат в качестве документации.

Для более сложных модулей (например, моего корневого модуля) я мог бы использовать Modules.override () , чтобы переопределить привязки, которые мне не нужны во время тестирования (например, если я хочу проверить, что мой корневой объект, который будет создан, я, вероятно, не хочу, чтобы он создавал объект, который будет подключаться к базе данных). Для простых проектов вы можете протестировать только модуль верхнего уровня.

Обратите внимание, что Guice не будет вводить нули , если поле не помечено @Nullable , поэтому вам очень редко нужно проверять, что введенные объекты не равны нулю в ваших тестах.Фактически, когда я аннотирую конструкторы с помощью @Inject , я не утруждаюсь проверять, являются ли параметры null (на самом деле, мои тесты часто вводят null в конструктор, чтобы тесты были простыми).