Spring контекстные тесты не могут найти места конфигурации

Question

У меня большое приложение, распределенное по нескольким XML-файлам определения bean-компонентов Spring. В моем наборе тестов я вручную загружаю нужные мне XML-файлы, используя FileSystemXmlApplicationContext для выполнения тестов, которые я хочу запустить. Это сокращает время настройки теста и позволяет мне использовать те же самые файлы конфигурации, которые используются в производстве.

Теперь я пытаюсь использовать базовые классы транзакционного теста Spring, которые берут конфигурационные местоположения и загружают для меня контекст. По какой-то причине при создании контекста приложения Spring не может найти ни один из файлов конфигурации. Это сбивает с толку, потому что я запускаю тест из того же рабочего каталога, что и при загрузке конфигурации самостоятельно, используя FileSystemXmlApplicationContext. Если я добавлю все свои конфигурации в файл «file:», пути, которые я укажу в моем тесте, будут найдены, но любые файлы, которые импортированы или на которые ссылаются компоненты, определенные в конфигурации (например, файлы свойств), не могут быть найдены. В чем дело? Могу ли я получить тесты, расширяющие классы весенних контекстных тестов, чтобы они работали так же, как те, в которых я сам создаю контекст?

Например, создание такого контекста работает нормально:

ApplicationContext ctx = new FileSystemXmlApplicationContext(new String[] { "WEB-INF/services-context.xml"})

Если я расширяю AbstractTransactionalDataSourceSpringContextTests, следующее не находит services-context.xml:

@Override
protected String[] getConfigLocations() {
   return new String[] { "WEB-INF/services-context.xml"};
}

Это находит контекст служб, но определенный там PropertyPlaceholderConfigurer не может найти файлы своих свойств.

 @Override
 protected String[] getConfigLocations() {
    return new String[] { "file:WEB-INF/services-context.xml"};
 }

Answer 1

Мы помещаем все наши файлы конфигурации и свойств Spring в classpath, что упрощает задачу - мы можем просто расширить наши тестовые классы из базового класса, например:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={
        "/spring/*.xml", 
        "/testSpring/*.xml" })
public abstract class AbstractIntegrationTest  {

Здесь все пути - это пути в classpath.

Если вы не хотите этого делать, проверяли ли вы, как вы ссылаетесь на файлы свойств в вашем services-context.xml? Я подозреваю, что если вы добавите file: в вашу конфигурацию контекста, то вам также нужно добавить это в ссылку на файл свойств. Возможно, вы могли бы просто использовать отдельный тестовый конфигурационный файл Spring, чтобы изменить определение заполнителя вашего свойства, и поместить его в конец списка файлов контекста - его определения переопределят те, которые были определены в более ранних файлах.

Answer 2

В дополнение к переопределению getConfigLocations я также переопределил loadContext и использовал там надежный fileSystemXmlApplicationContext.

 @Override
 protected String[] getConfigLocations() {
     return new String[] { "WEB-INF/services-config.xml" };
 }

 @Override
 protected ConfigurableApplicationContext loadContext(String[] locations) throws Exception {
     return new FileSystemXmlApplicationContext(locations);
  }

Answer 3

Разве вы не можете использовать фабрики XML пути к классам, такие как ClassPathXmlApplicationContext ?

Answer 4

Ваши местоположения конфигурации являются относительными URI и будут интерпретироваться как таковые базовым тестовым классом, причем URI будет разрешаться относительно местоположения самого тестового класса. Попробуйте использовать полностью определенные URI или используйте относительный URI, учитывая, где находится тестовый класс.

Answer 5

ApplicationContext ctx = new FileSystemXmlApplicationContext(new String[] { "WebRoot/WEB-INF/services-context.xml"})

Answer 6

Другое возможное решение - дублировать services-config.xml и переименовать в services-config-test.xml, а затем поместить в classpath. То же самое относится и к файлу свойств.