Как можно выполнить очистку БД после ВСЕХ тестов в phpUnit?

Рейтинг: 0Ответов: 1Опубликовано: 09.01.2023

Имеется ли в phpUnit функция, которая позволяет очистить БД после выполнения всех имеющихся тестов? На данный момент мне удалось реализовать это через дроп-апдейт схемы БД, но это происходит после каждого тестового класса.

public static function tearDownAfterClass(): void
{
    exec('php bin/console doctrine:schema:drop --env test -f');
    exec('php bin/console doctrine:schema:update --env test -f');
}

tearDown() производится вообще после каждого теста в тестовом классе.

Есть ли возможность задать функцию, которая будет выполняться после всех тестов phpunit?

php phpunit
Источник: Stack Overflow на русском

Ответы

▲ 0Принят

Насколько знаю, в phpUnit нет возможности вызвать какой-то скрипт после выполнения всех тестов. Во-первых, концепция юнит-тестов не подразумевает тестирования бд (обращения к базе мокаются). Во-вторых, предполагается, что каждый отдельный тест инициирует и сбрасывает необходимое окружение (данные в бд в вашем случае) только для конкретного кейса (если тестируем пользователей, то ничего не знаем о статьях, например).

Но вы можете просто вызвать ваш скрипт после выполнения тестов:

phpunit ./tests && php my_tear_down_script.php

Или можете расширить стандартный ранер и добавить выполнение вашего скрипта.

Если вы хотите писать тесты с запросами в бд, то подумайте о том, как организовать параллельное выполнение таких тестов. Обычно в этом случае стартуют транзакцию, вставляют необходимые для теста данные в бд, тестуируют и откатывают транзакцию. Это позволяет избежать проблем, когда одновременно выполняющиеся тесты меняют одни и те же данные (например один тест проверяет добавление сущности, а другой получение списка сущностей). Но такое решение сильно зависит от того как вы управляете транзакциями в приложении.

Возможно имеет смысл отделить интеграционные тесты от юнит-тестов и использовать для них более подходящий фрэймворк. То есть вы пишите много юнит-тестов и мокаете запросы к бд и пишете необходимое (сильно меньшее чем юнитов) количество интеграционных тестов и разруливаете их общее состояние (например запускаете в строго определённом порядке).