Java Blog

Пакет 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...

Аннотирование метода теста с помощью @Transactional приводит к тому, что тест запускается в транзакции, которая по умолчанию автоматически откатывается после завершения теста. Если тестовый класс аннотируется @Transactional, каждый тестовый метод в этой иерархии классов выполняется внутри транзакции. Методы тестирования, не помеченные @Transactional (на уровне класса или метода), не выполняются в транзакции. Обратите внимание, что @Transactional не поддерживается в методах жизненного цикла теста - например, методы, аннотированные JUnit Jupiter @BeforeAll, @BeforeEach и т.д. Кроме того, тесты, аннотированные @Transactional, но имеющие атрибут propagation, установленный на NOT_SUPPORTED, не выполняются в пределах транзакции. Поддержка атрибута @Transactional Атрибут Поддерживается для транзакций, управляемых тестами value и transactionManager да propagation только Propagation.NOT_SUPPORTED и Propagation.NEVER поддерживаются isolation нет timeout нет readOnly нет...

В TestContext framework транзакциями управляет TransactionalTestExecutionListener, который настроен по умолчанию, даже если вы явно не объявляете @TestExecutionListeners в своем тестовом классе. Однако, чтобы включить поддержку транзакций, вы должны сконфигурировать bean-компонент PlatformTransactionManager в ApplicationContext, который загружается с семантикой @ContextConfiguration. Кроме того, вы должны объявить аннотацию Spring @Transactional либо на уровне класса, либо на уровне метода для ваших тестов. Тестовые транзакции Транзакции, управляемые тестом, - это транзакции, которые управляются декларативно с помощью TransactionalTestExecutionListener или программно с помощью TestTransaction. Вы не должны путать такие транзакции с транзакциями, управляемыми Spring (те, которые управляются непосредственно Spring в ApplicationContext, загруженном для тестов) или транзакциями, управляемыми приложением (те, которые управляются программно в коде приложения, который вызывается тестами). Т...

Spring поддерживает bean-компоненты с областью действия запроса и сеанса (request- и session-scoped beans) еще с ранних релизов, и вы можете протестировать bean-компоненты с областью действия запроса и сеанса, выполнив следующие действия: Убедитесь, что WebApplicationContext загружен для вашего теста, аннотируя тестовый класс с помощью @WebAppConfiguration. Внедрите фиктивный (mock) запрос или сеанс в свой тестовый экземпляр и при необходимости подготовьте тестовое приспособление. Вызовите свой веб-компонент, полученный из настроенного контекста WebApplicationContext (с внедрением зависимостей). Выполняйте утверждения против моков. Следующий фрагмент кода показывает конфигурацию XML для варианта использования входа (login). Обратите внимание, что bean-компонент userService зависит от bean-компонента loginAction в области запроса. Кроме того, LoginAction создается с помощью выражений SpEL, которые извлекают имя пользователя и пароль из текущего HTTP-запроса. В нашем тесте мы хоти...

Когда вы используете DependencyInjectionTestExecutionListener (который настроен по умолчанию), зависимости ваших тестовых экземпляров вводятся из bean-компонентов в контексте приложения, который вы настроили с помощью @ContextConfiguration или связанных аннотаций. Вы можете использовать внедрение сеттера, внедрение поля или и то, и другое, в зависимости от того, какие аннотации вы выбираете и размещаете ли вы их в методах или полях установщика. Если вы используете JUnit Jupiter, вы также можете дополнительно использовать внедрение конструктора (внедрение зависимостей с помощью SpringExtension). Для обеспечения согласованности с поддержкой Spring на основе аннотаций вы также можете использовать аннотацию Spring @Autowired или аннотацию @Inject из JSR-330 для внедрения полей и установщиков. Для фреймворков тестирования, отличных от JUnit Jupiter, TestContext framework не участвует в создании экземпляра тестового класса. Таким образом, использование @Autowired или @Inject для конструктор...

При написании интеграционных тестов, основанных на загруженном Spring ApplicationContext, часто бывает достаточно тестирования в одном контексте. Однако бывают случаи, когда полезно или даже необходимо протестировать иерархию экземпляров ApplicationContext. Например, если вы разрабатываете веб-приложение Spring MVC, у вас обычно есть корневой WebApplicationContext, загруженный Spring ContextLoaderListener, и дочерний WebApplicationContext, загруженный Spring DispatcherServlet. Это приводит к иерархии родительско-дочернего контекста, в которой общие компоненты и конфигурация инфраструктуры объявляются в корневом контексте и используются в дочернем контексте веб-компонентами. Другой вариант использования можно найти в приложениях Spring Batch, где у вас часто есть родительский контекст, который обеспечивает конфигурацию для разделяемой пакетной инфраструктуры, и дочерний контекст для конфигурации определенного пакетного задания. Вы можете писать интеграционные тесты, использующие контек...

Как только TestContext framework загружает ApplicationContext (или WebApplicationContext) для теста, этот контекст кэшируется и повторно используется для всех последующих тестов, которые объявляют ту же уникальную конфигурацию контекста в одном и том же наборе тестов. Чтобы понять, как работает кэширование, важно понимать, что имеется в виду под "уникальным" и "набором тестов". ApplicationContext можно однозначно идентифицировать по комбинации параметров конфигурации, которые используются для его загрузки. Следовательно, уникальная комбинация параметров конфигурации используется для генерации ключа, под которым кэшируется контекст. TestContext framework использует следующие параметры конфигурации для создания ключа кэша контекста: locations (из @ContextConfiguration) classes (из @ContextConfiguration) contextInitializerClasses (из @ContextConfiguration) contextCustomizers (из ContextCustomizerFactory) - это включает методы @DynamicPropertySource, а также разли...

Чтобы проинструктировать 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/tes...