Очистка базы при тестах API
Привет!
Если честно, не думал что тут наберется больше полтора землекопа, но как-то набралось, что мотивирует писать делиться😁
Вчера решал вечный вопрос: как поддерживать базу чистой при тестах АПИшки, чтобы тест не валился на "ой, эта запись уже есть в базе, чувачок!" Кто-то скажет: используй random и все. Да, может так было и легче, но я хотел подконтрольно реализовать.
Скажу сразу: особо какую-то магию я не открываю, просто делюсь прогрессом.
В общем я реализовал это так: фикстура с названием cleanup_db, где через psycopg2 подключается к базе(креды для подключения вбиты в .env и добавлены в .gitignore, +1 очко), создается conn и cursor, затем выполняется грубый truncate table tablename restart identity cascade и дальше закрывается курсор и коннект. И самое важное: у этой фикстуры в параметрах стоит scope="function" и autouse="True", что гарантирует выполнение очистки базы после каждого теста.
Cascade я использовал специально, т.к. у нас много FK и мне не хотелось тратить время на сбор портянки для очистки одной таблицы. Да и поддерживать потом это не хочу. Стенд лично мой, работаю я там один, так что в своей песочнице я король😁
А касаемо данных, которые нужны в базе для проверки GET запросов: добавляется фикстура которая создает запись в бд, потом просто добавляется в параметры теста. Таким образом до начала теста сначала запускается фикстура создающая данные, потом весь тест и в конце очистка. Круто же
Источники: свои знания, немного гугла и чата взамен стековерфлоу(никакого копировать вставить, чисто справочная инфа), чашка кофе и кошка на коленях
· 15.05
Главное потом тест с продом не перепутать. А так да-вариант рабочий. Кстати деградации бд после кучи прогонов тестов не замечали?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 15.05
Нет, банально лишь по той причине, что сейчас этих тестов очень мало) А так, даже если деградация будет - всегда есть docker compose down и потом пересобрать заново) правда это костыль, к которому лучше не прибегать, в общем буду решать по мере поступления. А какие деградации могут быть? В голову приходят только касаемо сиквенсов, возможно согласованности данных. Ну сиквенсы сбрасываются с помощью restart identity при truncate. А согласованность - это скорее проблема мусорных заведенных данных. Можно еще конечно замерить насколько быстро отрабатывают скрипты после прогонов частых, но опять же - пока такая задача явно не на первом месте стоит)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 15.05
Ну там каждый раз же происходит io при чтении/записи. Лог какой-нибудь транзакционный растет и пр. сайд-эффекты) Тем более если это докер то все вызовы через прослойку виртуальной файловой системы до реального жесткого диска идут туда-сюда. Но это я так-подушнить. Сам активно тесты, работающие с бд и проверяющие логику раблты хп активно разрабатывал;)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён