Java Blog

Вы можете использовать тесты на стороне клиента для тестирования кода, который внутренне использует RestTemplate. Идея состоит в том, чтобы объявить ожидаемые запросы и предоставить "заглушки" (stubs) ответов, чтобы вы могли сосредоточиться на тестировании кода изолированно (то есть без запуска сервера). В следующем примере показано, как это сделать: RestTemplate restTemplate = new RestTemplate(); MockRestServiceServer mockServer = MockRestServiceServer .bindTo(restTemplate) .build(); mockServer.expect(requestTo("/greeting")) .andRespond(withSuccess()); // Тестовый код, // который использует вышеуказанный RestTemplate ... mockServer.verify(); В предыдущем примере MockRestServiceServer (центральный класс для клиентских REST-тестов) настраивает RestTemplate с помощью настраиваемой ClientHttpRequestFactory, которая утверждает фактические запросы против ожиданий и возвращает ...

Асинхронные запросы Servlet 3.0, поддерживаемые в Spring MVC, работают, выходя из потока контейнера сервлета и позволяя приложению вычислять ответ асинхронно, после чего выполняется асинхронная отправка для завершения обработки в потоке контейнера сервлета. В Spring MVC Test можно протестировать асинхронные запросы, сначала подтвердив созданное значение async, затем вручную выполнив асинхронную отправку и, наконец, проверив ответ. Ниже приведен пример теста для методов контроллера, которые возвращают DeferredResult, Callable или реактивный тип, например Reactor Mono: @Test void test() throws Exception { MvcResult mvcResult = this.mockMvc.perform(get("/path")) .andExpect(status().isOk()) // Статус ответа на проверку не изменился .andExpect(request().asyncStarted()) // Асинхронная обработка должна быть запущена .andExpect(request().asyncResult("body")) // Подождите и подтвердите результат async .andReturn(); ...

Вы можете определить ожидания, добавив один или несколько вызовов .andExpect(..) после выполнения запроса, как показано в следующем примере: mockMvc.perform(get("/accounts/1")) .andExpect(status().isOk()); MockMvcResultMatchers.* предоставляет ряд ожиданий, некоторые из которых дополнительно вложены в более подробные ожидания. Ожидания делятся на две общие категории. Первая категория утверждений проверяет свойства ответа (например, статус ответа, заголовки и содержимое). Это самые важные результаты, которые нужно утверждать. Вторая категория утверждений выходит за рамки ответа. Эти утверждения позволяют вам проверять конкретные аспекты Spring MVC, например, какой метод контроллера обработал запрос, было ли вызвано и обработано исключение, каково содержимое модели, какое представление было выбрано, какие атрибуты были добавлены и т. д. Они также позволяют вам проверять конкретные аспекты сервлета, такие как атрибуты запроса и сеанса. Следующий тест утверждает,...

Вы можете выполнять запросы, которые используют любой метод HTTP, как показано в следующем примере: mockMvc.perform(post("/hotels/{id}", 42) .accept(MediaType.APPLICATION_JSON)); Вы также можете выполнять запросы загрузки файлов, которые внутренне используют MockMultipartHttpServletRequest, чтобы не было фактического синтаксического анализа составного запроса. Скорее, вы должны настроить его, как в следующем примере: mockMvc.perform(multipart("/doc") .file("a1", "ABC".getBytes("UTF-8"))); Вы можете указать параметры запроса в стиле шаблона URI, как показано в следующем примере: mockMvc.perform(get("/hotels?thing={thing}", "somewhere")); Вы также можете добавить параметры запроса сервлета, которые представляют параметры запроса или формы, как показано в следующем примере: mockMvc.perform(get("/hotels").param("thing", "somewhere")); Если код прилож...

Независимо от того, какой конструктор MockMvc вы используете, все реализации MockMvcBuilder предоставляют некоторые общие и очень полезные функции. Например, вы можете объявить заголовок Accept для всех запросов и ожидать статус 200, а также заголовок Content-Type во всех ответах, как показано ниже: // static import of MockMvcBuilders.standaloneSetup MockMvc mockMvc = standaloneSetup(new MusicController()) .defaultRequest(get("/") .accept(MediaType.APPLICATION_JSON)) .alwaysExpect(status().isOk()) .alwaysExpect(content().contentType("application/json;charset=UTF-8")) .build(); Кроме того, сторонние платформы (и приложения) могут предварительно упаковать инструкции по установке, например, в MockMvcConfigurer. Spring Framework имеет одну такую встроенную реализацию, которая помогает сохранять и повторно использовать сеанс HTTP для разных запросов. Вы можете использовать его следующим образом: // static import of SharedHttpSessionConfi...

У вас есть два основных варианта создания экземпляра 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 { ...

Spring MVC Test framework обеспечивает первоклассную поддержку для тестирования кода Spring MVC с помощью свободного API, который вы можете использовать с JUnit, TestNG или любым другим фреймворком тестирования. Он построен на mock объектах Servlet API из модуля spring-test и, следовательно, не использует работающий контейнер сервлетов. Он использует DispatcherServlet для обеспечения полного поведения среды выполнения Spring MVC и обеспечивает поддержку загрузки фактической конфигурации Spring с TestContext framework в дополнение к автономному режиму, в котором вы можете вручную создавать экземпляры контроллеров и тестировать их по одному. Spring MVC Test также обеспечивает поддержку на стороне клиента для тестирования кода, использующего RestTemplate. Клиентские тесты имитируют ответы сервера, а также не используют работающий сервер. Spring Boot предоставляет возможность писать полные сквозные интеграционные тесты, которые включают работающий сервер. Серверные тесты Вы можете напи...

Пакет org.springframework.test.context.testng предоставляет следующие классы поддержки для тестовых случаев на основе TestNG: AbstractTestNGSpringContextTests AbstractTransactionalTestNGSpringContextTests AbstractTestNGSpringContextTests - это абстрактный базовый тестовый класс, который объединяет Spring TestContext Framework с явной поддержкой тестирования ApplicationContext в среде TestNG. Когда вы расширяете AbstractTestNGSpringContextTests, вы можете получить доступ к защищенной переменной экземпляра applicationContext, которую можно использовать для выполнения явных поисков bean-компонентов или для проверки состояния контекста в целом. AbstractTransactionalTestNGSpringContextTests - это абстрактное транзакционное расширение AbstractTestNGSpringContextTests, которое добавляет некоторые удобные функции для доступа JDBC. Этот класс ожидает, что bean-объект javax.sql.DataSource и bean-объект PlatformTransactionManager будут определены в ApplicationContext. Когда вы расширяете Ab...

SpringExtension реализует API расширения ParameterResolver из JUnit Jupiter, что позволяет Spring обеспечивать внедрение зависимостей для конструкторов тестов, методов тестирования и методов обратного вызова жизненного цикла тестирования. В частности, SpringExtension может внедрять зависимости из ApplicationContext теста в конструкторы и методы тестов, аннотированные с помощью @BeforeAll, @AfterAll, @BeforeEach, @AfterEach, @Test, @RepeatedTest, @ParameterizedTest и других. Внедрение конструктора Если конкретный параметр в конструкторе для тестового класса JUnit Jupiter имеет тип ApplicationContext (или его подтип) или аннотируется или метааннотируется с помощью @Autowired, @Qualifier или @Value, Spring вводит значение для этого конкретного с соответствующим bean-компонентом или значением из ApplicationContext теста. Spring также может быть настроен на автоматическое подключение всех аргументов для конструктора тестового класса, если конструктор считается автоматическим. Конструкто...

Spring TestContext Framework предлагает полную интеграцию со средой тестирования JUnit Jupiter, представленной в JUnit 5. Аннотируя тестовые классы с помощью @ExtendWith(SpringExtension.class), вы можете реализовать стандартные модульные и интеграционные тесты на основе JUnit Jupiter и одновременно воспользоваться преимуществами TestContext framework, такими как поддержка загрузки контекстов приложения, внедрение зависимостей тестовых экземпляров, выполнение транзакционного метода тестирования и т. д. Кроме того, благодаря богатому API расширений в JUnit Jupiter Spring предоставляет следующие функции помимо набора функций, которые Spring поддерживает для JUnit 4 и TestNG: Внедрение зависимостей для конструкторов тестов, методов тестирования и методов обратного вызова жизненного цикла теста. Мощная поддержка выполнения условного теста на основе выражений SpEL, переменных среды, системных свойств и т. д. Пользовательские составные аннотации, сочетающие аннотации из Spring и JUnit Ju...

Пакет org.springframework.test.context.junit4 предоставляет следующие классы поддержки для тестовых случаев на основе JUnit 4 (поддерживаются в JUnit 4.12 или выше): AbstractJUnit4SpringContextTests AbstractTransactionalJUnit4SpringContextTests AbstractJUnit4SpringContextTests - это абстрактный базовый тестовый класс, который объединяет Spring TestContext Framework с явной поддержкой тестирования ApplicationContext в среде JUnit 4. Когда вы расширяете AbstractJUnit4SpringContextTests, вы можете получить доступ к защищенной переменной экземпляра applicationContext, которую вы можете использовать для выполнения явного поиска bean-компонентов или для проверки состояния контекста в целом. AbstractTransactionalJUnit4SpringContextTests - это абстрактное транзакционное расширение AbstractJUnit4SpringContextTests, которое добавляет некоторые удобные функции для доступа JDBC. Этот класс ожидает, что bean-объект javax.sql.DataSource и bean-объект PlatformTransactionManager будут определены...

Пакет org.springframework.test.context.junit4.rules предоставляет следующие JUnit 4 Rules (поддерживаются в JUnit 4.12 и выше): SpringClassRule SpringMethodRule SpringClassRule - это JUnit TestRule, который поддерживает функции уровня класса Spring TestContext Framework, тогда как SpringMethodRule - это JUnit MethodRule, который поддерживает функции уровня экземпляра и уровня метода Spring TestContext Framework. В отличие от SpringRunner, поддержка JUnit на основе правил Spring имеет то преимущество, что не зависит от какой-либо реализации org.junit.runner.Runner и, следовательно, может быть объединена с существующими альтернативными runner (такими как JUnit 4 Parameterized) или сторонними runner (например, MockitoJUnitRunner). Чтобы поддерживать полную функциональность TestContext framework, вы должны объединить SpringClassRule с SpringMethodRule. В следующем примере показан правильный способ объявления этих правил в интеграционном тесте: // Опционально можно указать // не...

Spring TestContext Framework предлагает полную интеграцию с JUnit 4 через настраиваемый Runner (поддерживается в JUnit 4.12 или выше). Аннотируя тестовые классы с помощью @RunWith(SpringJUnit4ClassRunner.class) или более короткого варианта @RunWith(SpringRunner.class), разработчики могут реализовать стандартные модульные и интеграционные тесты на основе JUnit 4 и одновременно воспользоваться преимуществами TestContext framework, такими как поддержка для загрузки контекстов приложения, внедрение зависимостей тестовых экземпляров, выполнение транзакционного метода тестирования и т. д. Если вы хотите использовать Spring TestContext Framework с альтернативным средством выполнения (например, параметризованным средством выполнения JUnit 4) или сторонними средствами выполнения (например, MockitoJUnitRunner), вы можете при желании использовать вместо этого поддержку Spring для правил JUnit. В следующем листинге кода показаны минимальные требования для настройки тестового класса для работы с н...

Spring Framework 5.0 представил базовую поддержку для параллельного выполнения тестов в одной JVM при использовании Spring TestContext Framework. В общем, это означает, что большинство тестовых классов или тестовых методов можно запускать параллельно без каких-либо изменений в тестовом коде или конфигурации. Имейте в виду, что введение параллелизма в ваш набор тестов может привести к неожиданным побочным эффектам, странному поведению во время выполнения и тестам, которые дают сбой периодически или на вид случайным образом. Поэтому команда Spring предоставляет следующие общие рекомендации, когда не следует запускать тесты параллельно. Не запускайте тесты параллельно, если тесты: Используют поддержку @DirtiesContext в Spring Framework. Используют поддержку @MockBean или @SpyBean в Spring Boot. Используют поддержку @FixMethodOrder в JUnit 4 или любую функцию инфраструктуры тестирования, которая предназначена для обеспечения того, чтобы методы тестирования выполнялись в определенном ...

Вы можете настроить синтаксический анализ скрипта и обработку ошибок с помощью аннотации @SqlConfig. При объявлении аннотации уровня класса для интеграционного тестового класса @SqlConfig служит глобальной конфигурацией для всех SQL-скриптов в иерархии тестовых классов. При прямом объявлении с использованием атрибута config аннотации @Sql @SqlConfig служит локальной конфигурацией для SQL сценариев, объявленных во включенной аннотации @Sql. Каждый атрибут в @SqlConfig имеет неявное значение по умолчанию, которое задокументировано в javadoc соответствующего атрибута. Из-за правил, определенных для атрибутов аннотации в Спецификации языка Java, к сожалению, невозможно присвоить значение null атрибуту аннотации. Таким образом, для поддержки переопределений унаследованной глобальной конфигурации атрибуты @SqlConfig имеют явное значение по умолчанию либо "" (для строк), {} (для массивов) или DEFAULT (для перечислений). Этот подход позволяет локальным объявлениям @SqlConfig выборочн...

Если вам нужно настроить несколько наборов SQL сценариев для данного тестового класса или метода тестирования, но с другой конфигурацией синтаксиса, разными правилами обработки ошибок или разными фазами выполнения для каждого набора, вы можете объявить несколько экземпляров @Sql. В Java 8 вы можете использовать @Sql в качестве повторяемой аннотации. В противном случае вы можете использовать аннотацию @SqlGroup как явный контейнер для объявления нескольких экземпляров @Sql. В следующем примере показано, как использовать @Sql в качестве повторяющейся аннотации с Java 8: @Test @Sql(scripts = "/test-schema.sql", config = @SqlConfig(commentPrefix = "`")) @Sql("/test-user-data.sql") void userTest() { // запускаем код, // использующий тестовую схему и тестовые данные } В сценарии, представленном в предыдущем примере, сценарий test-schema.sql использует другой синтаксис для однострочных комментариев. Следующий пример идентичен предыдущему, за иск...

Декларативное выполнение SQL сценариев с помощью @Sql В дополнение к механизмам для программного запуска SQL сценариев вы можете декларативно настроить SQL сценарии в Spring TestContext Framework. В частности, вы можете объявить аннотацию @Sql в тестовом классе или тестовом методе, чтобы настроить отдельные операторы SQL или пути ресурсов к SQL сценариям, которые должны выполняться для данной базы данных до или после метода интеграционного тестирования. Поддержка @Sql обеспечивается SqlScriptsTestExecutionListener, который включен по умолчанию. Объявления @Sql на уровне метода по умолчанию переопределяют объявления уровня класса. Однако, начиная с Spring Framework 5.2, это поведение можно настроить для каждого тестового класса или для каждого тестового метода через @SqlMergeMode. Семантика ресурсов пути Каждый путь интерпретируется как ресурс Spring. Простой путь (например, "schema.sql") рассматривается как ресурс пути к классам, относящийся к пакету, в котором определен...

При написании интеграционных тестов для реляционной базы данных часто бывает полезно запускать SQL сценарии для изменения схемы базы данных или вставки тестовых данных в таблицы. Модуль spring-jdbc обеспечивает поддержку для инициализации встроенной или существующей базы данных путем выполнения SQL сценариев при загрузке Spring ApplicationContext. Хотя очень полезно инициализировать базу данных для тестирования один раз при загрузке ApplicationContext, иногда необходимо иметь возможность изменять базу данных во время интеграционных тестов. Программное выполнение SQL сценариев Spring предоставляет следующие параметры для программного выполнения SQL сценариев в рамках методов тестирования интеграции. org.springframework.jdbc.datasource.init.ScriptUtils org.springframework.jdbc.datasource.init.ResourceDatabasePopulator org.springframework.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests org.springframework.test.context.testng.AbstractTransactionalTestNGSpringConte...

В следующем примере на основе JUnit Jupiter показан вымышленный сценарий тестирования интеграции, в котором выделены все аннотации, связанные с транзакциями. Этот пример не предназначен для демонстрации передового опыта, а скорее для демонстрации того, как можно использовать эти аннотации. @SpringJUnitConfig @Transactional(transactionManager = "txMgr") @Commit class FictitiousTransactionalTest { @BeforeTransaction void verifyInitialDatabaseState() { // логика для проверки // начального состояния перед запуском транзакции } @BeforeEach void setUpTestDataWithinTransaction() { // настраиваем тестовые данные внутри транзакции } @Test // переопределяет аннотацию @Commit уровня класса @Rollback void modifyDatabaseWithinTransaction() { // логика, которая использует // тестовые данные и изменяет состояние базы данных } @AfterEach void tearDownWithinTransaction() { // запус...

Вы можете программно взаимодействовать с транзакциями управляемыми тестами, используя статические методы в TestTransaction. Например, вы можете использовать TestTransaction в тестовых методах, перед методами и после методов, чтобы начать или завершить текущую управляемую тестом транзакцию или настроить текущую управляемую тестом транзакцию для отката или фиксации. Поддержка TestTransaction автоматически доступна всякий раз, когда включен TransactionalTestExecutionListener. В следующем примере демонстрируются некоторые возможности TestTransaction. @ContextConfiguration(classes = TestConfig.class) public class ProgrammaticTransactionManagementTests extends AbstractTransactionalJUnit4SpringContextTests { @Test public void transactionalTest() { // проверяем начальное состояние // в тестовой базе данных: assertNumUsers(2); deleteFromTables("user"); // изменения в базе данных будут зафиксированы! TestTransact...