Spring: правильный способ имитировать бобы

#java #spring #unit-testing #mockito #spring-test

#java #весна #модульное тестирование #mockito #spring-тест

Вопрос:

У меня есть: такие компоненты, как

 <bean id="abstractBean" class="com.package.MyBean" abstract="true"/>

<bean id="heirBean" parent="abstractBean">
    <property name="someProperty" ref="anotherBean">
</bean>
  

Вопрос: Как издеваться heirBean ? Или, другими словами, как издеваться abstractBean ?


======================== НЕОБЯЗАТЕЛЬНАЯ ЧАСТЬ ВОПРОСА ==============================

Как я пытался это сделать [с исключением]:

 <bean id="abstractBean" class="MockFactoryBean">
    <property name="type" value="com.package.MyBean"/>
</bean>
  

MockFactoryBean.java

 public class MockFactoryBean<T> implements FactoryBean<T> {
    private Class<T> type;

    public void setType(Class<T> type) {
        this.type = type;
    }

    @Override
    public T getObject() throws Exception {
        return Mockito.mock(type);
    }

    @Override
    public Class<T> getObjectType() {
        return type;
    }

    @Override
    public boolean isSingleton() {
        return true;
    }

}
  

Проблема: я не могу установить поля макета.

Ответ №1:

Существует эта платформа, которая позволяет вам добавлять функциональность макетирования в ваш XML-файл Spring — https://bitbucket.org/kubek2k/springockito/wiki/Home

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

1. @user346561 пожалуйста, ознакомьтесь с преимуществами springockito по сравнению с моим подходом. Я имею в виду, что он может, чего не может мой подход. Я приму ваш ответ позже

Ответ №2:

Как правило, вы не издеваетесь над родительскими компонентами, вы издеваетесь над каждым компонентом, который хотите издеваться.

Насколько я понимаю вашу проблему:

  • у вас много компонентов
  • чем использовать некоторые общие функции
  • вы хотите издеваться над этой общей функциональностью

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

Я бы предложил:

  • перенос общей функциональности в отдельный интерфейс реализация
  • внедрение этой функциональности во все ваши компоненты, которые ее используют
  • имитируйте эту общую функциональность

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

Ответ №3:

Я бы использовал концепцию профиля spring; начиная с Spring 3.2.X, в Spring есть концепция «профиля», и вы можете использовать ее для макетирования своего компонента для области тестирования

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

1. но если мне нужно издеваться над одним-двумя компонентами. Разве это не большие накладные расходы на создание отдельного контекста для одного макета?

2. ну, вы можете создать этот новый контекст приложения (честно говоря, я использую аннотацию, поэтому мне не нужно создавать разные контексты приложения), и вы можете загрузить новый файл контекста только для тестового примера

3. но если у меня действительно большой контекст приложения, и мне нужно переопределить его отдельный компонент?