JUnit4, Spring, настройка тестового контекста Hibernate

Просто ищу небольшой совет о том, как настроить «модульное» тестирование с помощью JUnit4 в веб-приложении Spring 3.0.2 и Hibernate 3.2.7.

В настоящее время у нас есть чуть более 500 тестов, распределенных по более чем 75 классам.

Наши тестовые классы настроены (аннотированы) аналогично классу ниже:

@RunWith(SpringJUnit4ClassRunner.class)
@TransactionConfiguration
@Transactional
@ContextConfiguration(locations={"/location/of/SomeServiceTest-context.xml"}, inheritLocations=false)
public class SomeServiceTest extends AbstractTransactionalJUnit4SpringContextTests {

    @Autowired
    protected SomeService someService;

    @Test
    public void testSomeServiceMethod() {}

    @Test
    public void testAnotherServiceMethod() {}

}

Наши объекты «Сервис» аннотируются с помощью @Service(«serviceName») и имеют @Autowired (защищенные) зависимости, которые могут быть другими службами или DAO (с аннотацией @Repository(«daoName»)).

Раньше у нас были разные контексты для большинства тестовых классов. Каждый контекст содержал только необходимые bean-компоненты для тестов в этом классе, поэтому мы могли тестировать части приложения изолированно. Зависимости, которые не были определены в контексте, будут автоматически имитироваться AutoBeanDeclarer, который мы создали, вдохновившись этой статьей на DZone: Автоматически вставлять макеты в контекст Spring

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

java.lang.OutOfMemoryError: GC overhead limit exceeded

После некоторых поисков (и профилирования) мы обнаружили утечку памяти, как описано в этом сообщении: Утечка памяти следа приложения ClassLoader в общих контейнерах. Короче говоря, при установке мы загрузили несколько контекстов приложения, и они не были сборщиком мусора из-за наличия вложения в ClassLoader. Таким образом, у нас было множество объектов (SessionFactory), которые не собирали мусор, удерживая память.

Мы изменили нашу настройку, чтобы использовать один полный контекст приложения (со всеми определенными bean-компонентами), используемый всеми тестовыми классами. Это работает для обоих случаев; при запуске тестов по отдельности и при запуске всех тестов вместе.

Однако есть несколько проблем, которые мы хотим решить с помощью этой настройки:

Основная проблема заключается в том, что эта настройка не позволяет нам тестировать части приложения изолированно, потому что все компоненты и их зависимости определяются в контексте приложения, а не имитируются.

Вторая проблема заключается в том, что когда мы запускаем отдельные тесты, для загрузки контекста приложения требуется 30-40 секунд, что в конечном итоге приводит к обратным результатам, когда вам приходится запускать тест несколько раз.

Любые предложения/советы будут высоко оценены.

Я надеюсь, что я был достаточно ясен, не стесняйтесь задавать любые вопросы.

заранее спасибо

Мартин


person martin.masa    schedule 22.08.2011    source источник


Ответы (1)


Spring 3.1 представит XML-профили — это может быть хорошим способом работы с различными тестовыми настройками. Он должен быть выпущен в этом году. - хотя у них уже задержка с выпуском RC1. Тем не менее, я бы попробовал выпуск Milestone (я уже сделал).

person FrVaBe    schedule 22.08.2011
comment
спасибо за ваше предложение, но, к сожалению, обновление версии Spring на данный момент для нас не вариант. Я обязательно посмотрю на XML-профили, хотя это похоже на удобную функцию. - person martin.masa; 23.08.2011
comment
@ masa-255 Если обновление для вас не вариант, вы можете создать профильное решение самостоятельно, как я объяснил в этот ответ. - person FrVaBe; 23.08.2011