Керування транзакціями

@SpringJUnitConfig(TestConfig::class)
@Transactional
class HibernateUserRepositoryTests {
    @Autowired
    lateinit var repository: HibernateUserRepository
    @Autowired lateinit var sessionFactory: SessionFactory
    lateinit var jdbcTemplate: JdbcTemplate
    @Autowired fun setDataSource(dataSource: DataSource) {
        this.jdbcTemplate = JdbcTemplate(dataSource)
        } @Test
        fun createUser() {
        // відстежуємо початковий стан у тестовій базі даних:
        val count = countRowsInTable("user")
        val user = User()
        repository.save(user)
        // Щоб уникнути помилкових спрацьовувань при тестуванні потрібно ручне скидання
        sessionFactory.getCurrentSession().flush()
        assertNumUsers(count + 1)
        }
        private fun countRowsInTable(tableName: String): Int {
        return JdbcTestUtils.countRowsInTable(jdbcTemplate, tableName)
        }
        private fun assertNumUsers(expected: Int) {
        assertEquals("Number of rows in the [user] table.", expected, countRowsInTable("user "))
        }
        }
    

Як пояснюється в розділі "Логіка роботи при відкаті та фіксації транзакцій", немає необхідності очищати базу даних після виконання методу createUser (), оскільки будь-які зміни, внесені до бази даних, автоматично відкочуються TransactionalTestExecutionListener.

Логіка роботи при відкаті та фіксації транзакцій

За замовчуванням тестові транзакції автоматично відкочуються після завершення тесту; однак логіку роботи при фіксації та відкаті транзакцій можна налаштувати декларативно за допомогою анотацій @Commit та @Rollback. Докладніше див. відповідні записи в розділі, присвяченому підтримці анотацій.

Керування програмними транзакціями

Ти можеш взаємодіяти з керованими тестами транзакціями програмно, використовуючи статичні методи у TestTransaction. Наприклад, можна використовувати TestTransaction у тестових методах, методах "перед" і "після" для запуску або завершення поточної керованої тестом транзакції або для конфігурування поточної керованої тестом транзакції на відкат або фіксацію. Підтримка TestTransaction автоматично доступна завжди, коли включений слухач TransactionalTestExecutionListener.

У цьому прикладі показано деякі можливості TestTransaction. Докладнішу інформацію див. у javadoc TestTransaction.

@ContextConfiguration(classes = TestConfig.class)
public class ProgrammaticTransactionManagementTests extends
        AbstractTransactionalJUnit4SpringContextTests {
    @Test
    public void transactionalTest() {
        // підтверджуємо початковий стан у тестовій базі даних:
        assertNumUsers(2);
        deleteFromTables("user");
        // Зміни в базі даних будуть зафіксовані!
        TestTransaction.flagForCommit();
        TestTransaction.end();
        assertFalse(TestTransaction.isActive());
        assertNumUsers(0);
        TestTransaction.start();
        // виконувати інші дії з базою даних, які будуть
        // автоматично відкачені після завершення тесту...
    }
    protected void assertNumUsers(int expected) {
        assertEquals("Number of rows in the [user] table.", expected, countRowsInTable( "user"));
    }
}

@ContextConfiguration(classes = [TestConfig::class])
class ProgrammaticTransactionManagementTests : AbstractTransactionalJUnit4SpringContext ) {
    @Test
    fun transactionalTest() {
        // підтверджуємо початковий стан у тестовій базі даних:
        assertNumUsers(2)
        deleteFromTables("user")
        // зміни у базі даних будуть зафіксовані!
        TestTransaction.flagForCommit()
        TestTransaction.end()
        assertFalse(TestTransaction.isActive())
        assertNumUsers(0) TestTransaction.start()
        // виконуємо інші дії з базою даних, які будуть
        // автоматично відкачені після завершення тесту...
    }
    protected fun assertNumUsers(expected: Int) {
        assertEquals("Number of rows in the [user] table.", expected, countRowsInTable("user"))
    }
}

Виконання коду поза транзакцією

Іноді може знадобитися виконати певний код перед або після транзакційного тестового методу, але поза транзакційним контекстом — наприклад, для перевірки початкового стану бази даних перед запуском тесту або для перевірки очікуваної поведінки транзакційної фіксації після виконання тесту (якщо тест було налаштовано на фіксацію транзакції). TransactionalTestExecutionListener підтримує анотації @BeforeTransaction та @AfterTransactio.n саме для таких сценаріїв. Ти можеш анотувати будь-який void метод у тестовому класі або будь-який void метод за замовчуванням у тестовому інтерфейсі однієї з цих анотацій, а слухач TransactionalTestExecutionListener забезпечить, щоб твій метод "перед транзакцією" або "після транзакції" був запущений у потрібний час.

Будь-які методи "перед" (наприклад, методи, позначені анотацією @BeforeEach з JUnit Jupiter) та будь-які методи "після" (наприклад, методи, позначені анотацією @AfterEach з JUnit Jupiter) виконуються в межах транзакції. До того ж, методи, анотовані за допомогою анотації @BeforeTransaction або @AfterTransaction, не виконуються для тестових методів, які не налаштовані на виконання в межах транзакції.

Налаштування диспетчера транзакцій

TransactionalTestExecutionListener очікує, що в ApplicationContext зі Spring для тесту буде визначено бін PlatformTransactionManager. Якщо існує кілька екземплярів PlatformTransactionManager в межах ApplicationContext тесту, можна оголосити кваліфікатор, використовуючи анотацію @Transactional("myTxMgr") або @Transactional (transactionManager = "myTxMgr"), або TransactionManagementConfigurer може бути реалізований класом, позначеним анотацією @Configuration. Звернися до javadoc за TestContextTransactionUtils.retrieveTransactionManager() для ознайомлення з більш детальною інформацією про алгоритм, який використовується для пошуку диспетчера транзакцій у ApplicationContext тесту.

Демонстрація всіх анотацій, пов'язаних з транзакціями

У наступному прикладі на основі JUnit Jupiter відображено фіктивний сценарій інтеграційного тестування, в якому виділено всі анотації, пов'язані з транзакціями. Приклад не є демонстрацією передової практики, а скоріше є демонстрацією того, як їх можна використовувати. Додаткову інформацію та приклади конфігурації див. у розділі, присвяченому підтримці анотацій. Керування транзакціями для анотації @Sql містить додатковий приклад, який використовує анотацію @Sql для виконання декларативного SQL-скрипту з семантикою відкату транзакції за замовчуванням. У наступному прикладі показані відповідні анотації:

@SpringJUnitConfig
@Transactional(transactionManager = "txMgr")
@Commit
class FictitiousTransactionalTest {
    @BeforeTransaction
    void verifyInit
        // логіка перевірки достовірності початкового стану перед запуском транзакції
    }
    @BeforeEach
    void setUpTestDataWithinTransaction() {
        // встановлюємо тестові дані в рамках транзакції }
    @Test
        // перевизначає налаштування анотації @Commit на рівні класу
    @Rollback
    modifyDatabaseWithinTransaction() {
        // логіка, що використовує тестові дані та змінює стан бази даних
    }
    @AfterEach void tearDownWithinTransaction() {
        // запускаємо логіку "руйнування (tear down)" всередині транзакції
    }
    @AfterTransaction
    void verifyFinalDatabaseState() {
        // логіка перевірки достовірності кінцевого стану після транзакції
    }
}

@SpringJUnitConfig
@Transactional(transactionManager = "txMgr")
@Commit
class FictitiousTransactionalTest {
    @BeforeTransaction
    fun verifyInitialDatabaseState() {
        // логіка перевірки достовірності початкового стану перед запуском транзакції
    }
    @BeforeEach fun setUpTestDataWithinTransaction() {
        // встановлюємо тестові дані в рамках транзакції }
    @Test
        // перевизначає налаштування інструкції @Commit на рівні класу
    @Rollback
    fun modifyDatabaseWithinTransaction() {
        // логіка, що використовує тестові дані та змінює стан бази даних
    }
    @AfterEach
    fun tearDownWithinTransaction() {
        // запускаємо логіку "руйнування (tear down)" всередині транзакції
    }
    @AfterTransaction
    fun verifyFinalDatabaseState() {
        // логіка перевірки достовірності кінцевого стану після транзакції
}

// ...
@Autowired
SessionFactory sessionFactory;
@Transactional
@Test // очікуваного виключення немає!
public void falsePositive() {
    updateEntityInHibernateSession();
    // Хибне спрацювання: виняток буде згенеровано, як тільки сесія Hibernate
    // буде остаточно скинута (тобто у виробничому коді)
}
@Transactional
@Test(expected = ...)
public void updateWithSessionFlush() {
    updateEntityInHibernateSession
    // Щоб уникнути помилкових спрацьовувань при тестуванні потрібно ручне скидання
    sessionFactory.getCurrentSession().flush();
}
// ...

// ...
@Autowired lateinit var sessionFactory: SessionFactory
@Transactional
@Test
// очікуваного виключення немає!
fun falsePositive() {
    updateEntityInHibernateSession()
    // Помилкове спрацювання: виняток буде згенеровано, як тільки сесія Hibernate
    // буде остаточно скинута (тобто у виробничому коді)
}
@Transactional
@Test(expected = ...)
fun updateWithSessionFlush() {
    updateEntityInHibernateSession()
    // Щоб уникнути помилкових спрацьовувань при тестуванні потрібно ручне скидання
    sessionFactory.getCurrentSession().flush()
}
// ...

// ...
@PersistenceContext
EntityManager entityManager;
@Transactional
@Test // очікуваного виключення немає!
public void falsePositive() {
    updateEntityInJpaPersistenceContext();
    // Помилкове спрацювання: виняток буде згенеровано, як тільки
    // EntityManager з JPA буде остаточно скинутий (тобто у виробничому коді)
}
@Transactional
@Test(expected = ...)
public void
    updateWithEntityManagerFlush() {
    updateEntityInJpaPersistenceContext
    // Щоб уникнути помилкових спрацьовувань при тестуванні потрібно ручне скидання
    entityManager.flush();
}
// ...

// ...
@PersistenceContext
lateinit var entityManager:EntityManager
@Transactional
@Test // очікуваного виключення немає!
fun falsePositive() {
    updateEntityInJpaPersistenceContext()
    // Помилкове спрацювання: виняток буде згенеровано, як тільки
    // EntityManager з JPA буде остаточно скинутий (тобто у виробничому коді)
}
@Transactional
@Test(expected = ...)
void updateWithEntityManagerFlush() {
    updateEntityInJpaPersistenceContext()
    // Щоб уникнути помилкових спрацьовувань при тестуванні потрібно ручне скидання
    entityManager.flush()
}
// ...

// ...
@Autowired
JpaPersonRepository repo;
@PersistenceContext
EntityManager entityManager;
@Transactional
@Test void savePerson() {
    // EntityManager#persist(...) призводить до @PrePersist, але не @PostPersist
    repo.save(new Person("Jane"));
    // Для здійснення зворотного виклику з анотацією @PostPersist потрібно ручне скидання
    entityManager.flush();
    // Тестовий код, який використовує зворотній виклик з анотацією @PostPersist
    // був викликаний...
}
// ...

// ...
@Autowired
lateinit var repo: JpaPersonRepository
@PersistenceContext
lateinit var entityManager: EntityManager
@Transactional
@Test
fun savePerson() {
    // EntityManager#persist(...) призводить до @PrePersist, але не @PostPersist
    repo.save(Person("Jane"))
    // Для здійснення зворотного виклику з анотацією @PostPersist потрібно ручне скидання
    entityManager.flush()
    // Тестовий код, який використовує зворотний виклик з анотацією @PostPersist
    // був викликаний ...
}
// ...