Интеграционное тестирование в Spring: TestContext Framework, загрузка WebApplicationContext

Чтобы проинструктировать TestContext framework загружать WebApplicationContext вместо стандартного ApplicationContext, вы можете аннотировать соответствующий тестовый класс с помощью @WebAppConfiguration.

Присутствие @WebAppConfiguration в вашем тестовом классе указывает TestContext framework (TCF), что WebApplicationContext (WAC) должен быть загружен для ваших интеграционных тестов. В фоновом режиме TCF гарантирует, что MockServletContext создан и передан в WAC вашего теста. По умолчанию базовый путь к ресурсу для вашего MockServletContext установлен на src/main/webapp. Это интерпретируется как путь относительно корня вашей JVM (обычно путь к вашему проекту). Если вы знакомы со структурой каталогов веб-приложения в проекте Maven, вы знаете, что src/main/webapp - это расположение по умолчанию для корня вашего WAR. Если вам нужно переопределить это значение по умолчанию, вы можете указать альтернативный путь к аннотации @WebAppConfiguration (например, @WebAppConfiguration("src/test/webapp")). Если вы хотите ссылаться на базовый путь к ресурсам из пути к классам вместо файловой системы, вы можете использовать Spring префикс classpath:.

Обратите внимание, что поддержка Spring для тестирования реализаций WebApplicationContext не уступает поддержке стандартных реализаций ApplicationContext. При тестировании с помощью WebApplicationContext вы можете объявлять файлы конфигурации XML, сценарии Groovy или классы @Configuration с помощью @ContextConfiguration. Вы также можете использовать любые другие тестовые аннотации, такие как @ActiveProfiles, @TestExecutionListeners, @Sql, @Rollback и другие.

Примеры в этом посте показывают некоторые из различных вариантов конфигурации для загрузки WebApplicationContext. В следующем примере показано, как TestContext framework поддерживает соглашение поверх конфигурации:

@ExtendWith(SpringExtension.class)

// по умолчанию "file:src/main/webapp"
@WebAppConfiguration

// обнаруживает "WacTests-context.xml" в том же пакете
// или статические вложенные классы @Configuration
@ContextConfiguration
class WacTests {
    //...
}

Если вы аннотируете тестовый класс с помощью @WebAppConfiguration без указания базового пути к ресурсам, путь к ресурсу по умолчанию будет равен file:src/main/webapp. Точно так же, если вы объявляете @ContextConfiguration без указания местоположений ресурсов, классов компонентов или инициализаторов контекста, Spring пытается обнаружить присутствие вашей конфигурации, используя соглашения (то есть WacTests-context.xml в том же пакете, что и класс WacTests или статические вложенные классы @Configuration).

В следующем примере показано, как явно объявить базовый путь к ресурсам с помощью @WebAppConfiguration и расположение ресурса XML с помощью @ContextConfiguration:

@ExtendWith(SpringExtension.class)

// ресурс файловой системы
@WebAppConfiguration("webapp")

// ресурс пути к классам
@ContextConfiguration("/spring/test-servlet-config.xml")
class WacTests {
    //...
}

Здесь важно отметить различную семантику для путей с этими двумя аннотациями. По умолчанию пути к ресурсам @WebAppConfiguration основаны на файловой системе, тогда как расположение ресурсов @ContextConfiguration основано на путях к классам.

В следующем примере показано, что мы можем переопределить семантику ресурса по умолчанию для обеих аннотаций, указав префикс ресурса Spring:

@ExtendWith(SpringExtension.class)

// ресурс пути к классам
@WebAppConfiguration("classpath:test-web-resources")

// ресурс файловой системы
@ContextConfiguration("file:src/main/webapp/WEB-INF/servlet-config.xml")
class WacTests {
    //...
}

Работа с Web Mocks

Для обеспечения всесторонней поддержки веб-тестирования в TestContext framework есть ServletTestExecutionListener, который включен по умолчанию. При тестировании с помощью WebApplicationContext этот TestExecutionListener устанавливает локальное состояние потока по умолчанию с помощью Spring Web RequestContextHolder перед каждым тестовым методом и создает MockHttpServletRequest, MockHttpServletResponse и ServletWebRequest на основе базового пути к ресурсу, настроенного с помощью @WebAppContextContextHolder. ServletTestExecutionListener также гарантирует, что MockHttpServletResponse и ServletWebRequest могут быть введены в тестовый экземпляр, и после завершения теста он очищает локальное состояние потока.

После того, как вы загрузили WebApplicationContext для вашего теста, вы можете обнаружить, что вам нужно взаимодействовать с веб моками - например, для настройки вашей тестовой фикстуры или для выполнения утверждений после вызова вашего веб-компонента. В следующем примере показано, какие моки можно автоматически подключить к вашему тесту. Обратите внимание, что WebApplicationContext и MockServletContext кэшируются в наборе тестов, тогда как другие моки управляются для каждого метода тестирования с помощью ServletTestExecutionListener.

@SpringJUnitWebConfig
class WacTests {

    @Autowired
    WebApplicationContext wac; // кэшируется

    @Autowired
    MockServletContext servletContext; // кэшируется

    @Autowired
    MockHttpSession session;

    @Autowired
    MockHttpServletRequest request;

    @Autowired
    MockHttpServletResponse response;

    @Autowired
    ServletWebRequest webRequest;

    //...
}

---

Читайте также:

• Интеграционное тестирование в Spring: TestContext Framework, конфигурация контекста с профилями среды
• Интеграционное тестирование в Spring: TestContext Framework, конфигурация контекста с источниками тестовых свойств
• Интеграционное тестирование в Spring: TestContext Framework, конфигурация контекста с динамическими источниками свойств