#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. но если у меня действительно большой контекст приложения, и мне нужно переопределить его отдельный компонент?