Макет фреймворка работает с фреймворком внедрения зависимостей в модульном тестировании

#guice #easymock #roboguice

#guice #easymock #roboguice

Вопрос:

Когда я пишу тесты с помощью EasyMock и Guice framework, я сталкиваюсь с проблемой. Код выглядит так:

 class A {
    B b;

    @Inject
    public A(B b) {
        this.b = b;
        this.b.addListener(this);
    }
}

class ATest {
    @Inject
    A a;

    B b;

    class InjectionModule extends AbstractModule {
        protected void configure() {
            b = createMock(B.class);
            bind(B.class).toInstance(b);
        }
    }

    public void setUp() {
        createInjector(new InjectionModule()).injectMembers(this);
    }

    public void testSomething() {
        replay(b);
        a.doSomething();
        verify(b);
    }
}
  

В ATest я заменяю реализацию B на макет объекта. Но когда инжектор создает экземпляр A, B.addListener() вызывается в A конструкторе, и, к сожалению, этот вызов записывается EasyMock, даже если я этого никогда не ожидал.

Поэтому моя проблема в том, что EasyMock ожидает, что я буду вызывать B.addListener() в каждом тестовом случае ATest . Пожалуйста, дайте мне какие-либо предложения по преодолению этого. Спасибо.

Комментарии:

1. Наконец, я отбрасываю макет фреймворка. После недели работы я использую наследование для макета класса и заменяю реализацию test taret фреймворком DI. Теперь мой модульный тест прост в написании и более понятен. Я считаю, что философия DI framework подходит для модульного тестирования, она помогает мне корректно заменить реализацию test target. С другой стороны, mock framework помог мне при модульном тестировании, но он не такой мощный, как mockito, и имеет много ограничений.

2. Когда DI и mock framework не могут работать вместе, я решаю отказаться от mock framework. Может быть, кто-то еще найдет полезным использовать только макет фреймворка.

Ответ №1:

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

Почему бы вам просто не создать экземпляр A самостоятельно и в процессе удалить 8 строк кода?

Комментарии:

1. Потому что вы часто можете использовать фреймворк DI для упрощения процесса макетирования для больших баз кода.