Комментарии 3
Если тесты используют базу, то попытка запустить их в разных процессах может вызвать конфликт доступа к данным.
А рабочее приложение как функционирует, если тесты могут вызывать конфликты?
Привет.
Проблемы при параллельной работе тестов и правда могут быть вызваны не продуманной архитектурой приложения. Но тут мы говорим не об этом. Мы рассматриваем ситуацию когда из-за параллельного запуска нарушается изоляция тестов, из-за этого тест не может корректно проверить юзкейс или запуститься.
Например, есть два теста один проверяет создание записи в базе, а другой проверяет ошибку, возникающую при попытке получить не существующие запись. Если первый тест создаст запись раньше и не успеет очистить ее после себя, второй найдет ее и юзкейс с ошибкой не будет проверен.
Также стоит сказать, что для тестирования сложной бизнес-логики часто приходится создавать окружение с помощью вызова фикстур или фабрик. Если мы запустим в параллель два теста, использующих одинаковое окружение, то при попытке дважды создать одно и тоже окружение (одни и те же записи в базе для тестов), могут возникнуть ошибки.
Например, у тебя переиспользуется фикстура которая создает запись с уникальным полем. Тогда один из тестов, работающих параллельно просто не запустится, тк не сможет применить фикстуру.
когда из-за параллельного запуска нарушается изоляция тестов, из-за этого тест не может корректно проверить юзкейс или запуститься
В большинстве случаев это и означает кривую реализацию тестов и/или самого приложения. Если на сайт больше одного пользователя зашло, он же не ломается. А почему тесты не работают?
Например, есть два теста один проверяет создание записи в базе, а другой проверяет ошибку, возникающую при попытке получить не существующие запись.
Создание записи в базе проверяется по айдишнику, сделали запись, получили айди (если айдишник генерится на клиенте, еще проще), потом проверили что запись создалась и все поля сохранились как надо. Тест, который проверяет логику работы с несуществующей записью, пытается получить запись по заведомо несуществующему айдишнику и другие тесты ему мешать не должны. У вас же рабочее приложение не ломается от того, что кто-то создал запись в базе. Поэтому и тесты не должны.
Конечно, ситуации бывают всякие, иногда надо и строго определенное окружение, например в базе должно быть именно 3 записи о продажах, чтобы проверить как строится отчет по продажам, что туда попадает что надо, а что не надо не попадает. Но все же более правильно постараться изменить подход к тестам и возможно к архитектуре приложения, а не подгонять окружение под каждый тест. Иначе можно получить тесты которые правильно работают только после подгонки окружения, а рабочее приложение постоянно сыпется.
Pytest-xdist: как распараллелить тесты без конфликтов в базе