Одна из причин, по которой пружина описывается как удобная для тестирования, заключается в том, что в модульном тесте может быть легко просто новый или макет.
В качестве альтернативы мы с большим успехом использовали следующую настройку, и я думаю, что она достаточно близка к тому, что вы хотите, я бы настоятельно рекомендовал бы ее:
Для всех bean-компонентов, которые нуждаются в разных реализациях в разных контекстах, переключитесь на разводку на основе аннотаций. Вы можете оставить остальные как есть.
Реализация следующего набора аннотаций
<context:component-scan base-package="com.foobar">
<context:include-filter type="annotation" expression="com.foobar.annotations.StubRepository"/>
<context:include-filter type="annotation" expression="com.foobar.annotations.TestScopedComponent"/>
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Repository"/>
</context:component-scan>
Затем вы аннотируете свои живые реализации с @Repository, ваши заглушки реализации с @StubRepository, любой код, который должен присутствовать только в модульном тесте с @TestScopedComponent. Вам может понадобиться еще пара аннотаций, но это хорошее начало.
Если у вас много spring.xml, вам, вероятно, потребуется создать несколько новых весенних xml-файлов, которые в основном содержат только определения компонентного сканирования. Обычно вы просто добавляете эти файлы в свой обычный список @ContextConfiguration. Причина этого в том, что вы часто сталкиваетесь с различными конфигурациями сканирования контекста (поверьте, вы сделаете по крайней мере еще 1 аннотацию, если вы проводите веб-тесты, что соответствует 4 релевантным комбинации)
Тогда вы в основном используете
@ContextConfiguration(locations = { "classpath:/path/to/root-config.xml" })
@RunWith(SpringJUnit4ClassRunner.class)
Обратите внимание, что эта настройка не позволяет вам иметь чередующиеся комбинации данных-заглушек / живых данных. Мы попробовали это, и я думаю, что это привело к путанице, которую я бы никому не рекомендовал;) Мы либо подключили полный набор заглушек, либо полный набор живых сервисов.
Мы используем в основном заглушки с автоматическим подключением при тестировании графического интерфейса рядом с вещами, где зависимости обычно довольно существенны. В более чистых областях кода мы используем более регулярное юнит-тестирование.
В нашей системе у нас есть следующие xml-файлы для сканирования компонентов:
- для обычного веб-производства
- для запуска веб только с заглушками
- для интеграционных тестов (в junit)
- для юнит-тестов (в юнитах)
- для веб-тестов на селен (в junit)
Это означает, что у нас есть 5 различных системных настроек, с которыми мы можем запустить приложение. Поскольку мы используем только аннотации, Spring достаточно быстр, чтобы автоматически связывать даже те модульные тесты, которые мы хотим подключить. Я знаю, что это нетрадиционно, но это действительно здорово.
Наши интеграционные тесты запускаются с полной настройкой в реальном времени, и один или два раза я решил получить действительно прагматичных и хочу иметь 5 живых вайрингов и один макет:
public class HybridTest {
@Autowired
MyTestSubject myTestSubject;
@Test
public void testWith5LiveServicesAndOneMock(){
MyServiceLive service = myTestSubject.getMyService();
try {
MyService mock = EasyMock.create(...)
myTestSubject.setMyService( mock);
.. do funky test with lots of live but one mock object
} finally {
myTestSubject.setMyService( service);
}
}
}
Я знаю, что пуристы-тестисты будут за мной повсюду Но иногда это просто очень прагматичное решение, которое оказывается очень элегантным, когда альтернатива будет действительно очень уродливой. Опять же, это обычно в тех местах, где есть GUI.