Интеграционное тестирование в Spring: Spring MVC Test Framework, варианты установки

У вас есть два основных варианта создания экземпляра MockMvc. Первый - загрузить конфигурацию Spring MVC через TestContext framework, которая загружает конфигурацию Spring и вводит WebApplicationContext в тест, чтобы использовать его для создания экземпляра MockMvc. В следующем примере показано, как это сделать:

@SpringJUnitWebConfig(locations = "my-servlet-context.xml")
class MyWebTests {

    MockMvc mockMvc;

    @BeforeEach
    void setup(WebApplicationContext wac) {
        this.mockMvc = MockMvcBuilders
                       .webAppContextSetup(this.wac)
                       .build();
    }

    // ...

}

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

class MyWebTests {

    MockMvc mockMvc;

    @BeforeEach
    void setup() {
        this.mockMvc = MockMvcBuilders
                       .standaloneSetup(new AccountController())
                       .build();
    }

    // ...

}

Какой вариант настройки следует использовать?

WebAppContextSetup загружает вашу фактическую конфигурацию Spring MVC, что приводит к более полному тесту интеграции. Поскольку TestContext framework кэширует загруженную конфигурацию Spring, она помогает поддерживать быструю работу тестов, даже если вы добавляете больше тестов в свой набор тестов. Кроме того, вы можете внедрить фиктивные (mock) службы в контроллеры через конфигурацию Spring, чтобы сосредоточиться на тестировании веб-слоя. В следующем примере объявляется фиктивный сервис с Mockito:

<bean id="accountService" class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="org.example.AccountService"/>
</bean>

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

@SpringJUnitWebConfig(locations = "test-servlet-context.xml")
class AccountTests {

    @Autowired
    AccountService accountService;

    MockMvc mockMvc;

    @BeforeEach
    void setup(WebApplicationContext wac) {
        this.mockMvc = MockMvcBuilders
                       .webAppContextSetup(wac)
                       .build();
    }

    // ...

}

С другой стороны, standaloneSetup немного ближе к модульному тесту. Он проверяет один контроллер за раз. Вы можете вручную ввести контроллер с фиктивными зависимостями, и это не требует загрузки конфигурации Spring. Такие тесты больше ориентированы на стиль и упрощают определение того, какой контроллер тестируется, требуется ли для работы какая-либо конкретная конфигурация Spring MVC и так далее. StandaloneSetup также является очень удобным способом написания специальных тестов для проверки конкретного поведения или для отладки проблемы.

Как и в большинстве споров "интеграционные против модульных тестов", здесь нет правильного или неправильного ответа. Однако использование standaloneSetup подразумевает необходимость дополнительных тестов webAppContextSetup для проверки вашей конфигурации Spring MVC. В качестве альтернативы вы можете написать все свои тесты с помощью webAppContextSetup, чтобы всегда проверять вашу фактическую конфигурацию Spring MVC.

---

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

• Интеграционное тестирование в Spring: Spring MVC Test Framework
• Интеграционное тестирование в Spring: TestContext Framework, внедрение зависимостей с помощью SpringExtension
• Интеграционное тестирование в Spring: TestContext Framework, классы поддержки TestNG