Spring підтримує біни, що входять до області видимості на рівні запиту та сесії, з ранніх версій, тому ти можеш тестувати такі біни, виконавши такі кроки:

  • Переконайся, що WebApplicationContext завантажений для твого тесту, анотувавши ваш тестовий клас за допомогою @WebAppConfiguration.

  • Введи імітуючий запит або сесію до твого тестового екземпляра і підготуй тестовий стенд відповідним чином.

  • Виклич свій вебкомпонент, який отримано з налаштованого WebApplicationContext (за допомогою впровадження залежностей).

  • Виконай твердження щодо об'єктів-імітацій.

Наступний фрагмент коду показує XML-конфігурацію для використання входу в систему. Зверни увагу, що бін userService залежить від біна loginAction, що знаходиться в області видимості на рівні запиту. До того ж, екземпляр LoginAction створюється за допомогою виразів на мові SpEL, які отримують ім'я користувача та пароль із поточного HTTP-запиту. У нашому тесті нам потрібно налаштувати ці параметри запиту через об'єкт-імітацію, керований фреймворком TestContext. У наступному лістингу показано конфігурацію для цього варіанта використання:

Конфігурація біна, що входить до області видимості на рівні запиту
<beans>
    <bean id="userService" class="com.example.SimpleUserService"
            c:loginAction-ref="loginAction"/>
    <bean id="loginAction" class="com.example.LoginAction"
            c:username="#{request.getParameter('user')}"
            c:password="#{request.getParameter('pswd')}"
            scope="request">
        <aop:scoped-proxy/>
    </bean>
</beans>

У RequestScopedBeanTests ми впроваджуємо як UserService (тобто об'єкт, що тестується), так і MockHttpServletRequest до нашого тестового екземпляру. У тестовому методі requestScope() ми налаштовуємо наш тестовий стенд, встановлюючи параметри запиту у наданому MockHttpServletRequest. Якщо для нашого userService буде викликаний метод loginUser(), то ми переконаємося, що спеціальна служба отримає доступ до біна loginAction, що знаходиться в області видимості на рівні запиту біна loginAction для поточного MockHttpServletRequest (тобто того, в якому ми тільки-но встановили параметри). Потім можна виконати твердження щодо результатів на основі відомих вхідних даних для імені користувача та пароля. У наступному лістингу показано, як це зробити:

Java
@SpringJUnitWebConfig
class RequestScopedBeanTests {
    @Autowired UserService userService;
    @Autowired MockHttpServletRequest request;
    @Test
    void requestScope() {
        request.setParameter("user", "enigma");
        request.setParameter("pswd", "$pr!ng");
        LoginResults results = userService.loginUser();
        // підтверджуємо результати
    }
}
Kotlin
@SpringJUnitWebConfig
class RequestScopedBeanTests {
    @Autowired lateinit var userService: UserService
    @Autowired lateinit var request: MockHttpServletRequest
    @Test
    fun requestScope() {
        request.setParameter("user", "enigma")
        request.setParameter("pswd", "\$pr!ng")
        val results = userService.loginUser()
        // підтверджуємо результати
    }
}

Наступний фрагмент коду схожий на той, який ми бачили раніше для біна, що входить до області видимості лише на рівні запиту. Однак цього разу бін userService має залежність від біна userPreferences, що входить до області видимості на рівні сесії. Зверни увагу, що екземпляр біна UserPreferences створюється за допомогою виразу на мові SpEL, який витягує тему з поточної сеансу HTTP. У нашому тесті нам потрібно налаштувати тему в сесії, що імітує, керованої фреймворком TestContext. У цьому прикладі показано, як це зробити:

Конфігурація біна, що входить до області видимості на рівні сесії
<beans>
    <bean id="userService" class="com.example.SimpleUserService"
            c:userPreferences-ref="userPreferences" />
    <bean id="userPreferences" class="com.example.UserPreferences"
            c:theme="#{session.getAttribute('theme')}"
            scope="session">
        <aop:scoped-proxy/>
    </bean>
</beans>

У SessionScopedBeanTests ми впроваджуємо UserService та MockHttpSession до нашого тестового екземпляру. У тестовому методі sessionScope() ми налаштовуємо наш тестовий стенд, встановлюючи очікуваний атрибут theme у наданому MockHttpSession. Якщо для нашого userService буде викликаний метод processUserPreferences(), ми переконаємося, що спеціальна служба отримає доступ до біна userPreferences, який знаходиться в області видимості на рівні сесії. для поточного MockHttpSession та зможемо виконати твердження щодо результатів на основі конфігурованої теми. У цьому прикладі показано, як це зробити:

Java
@SpringJUnitWebConfig
class SessionScopedBeanTests {
    @Autowired UserService userService;
    @Autowired MockHttpSession session;
    @Test
    void sessionScope() throws Exception {
        session.setAttribute("theme", "blue");
        Results results = userService.processUserPreferences();
        // підтверджуємо результати
    }
}
Kotlin
@SpringJUnitWebConfig
class SessionScopedBeanTests {
    @Autowired lateinit var userService: UserService
    @Autowired lateinit var session: MockHttpSession
    @Test
    fun sessionScope() {
        session.setAttribute("theme", "blue")
        val results = userService.processUserPreferences()
        // підтверджуємо результати
    }
}