Жизненный цикл тестовых данных: создать, проверить, убрать

Оля · DevOps, #qa-antrakt

Ночной прогон на общем стенде упал по таймауту. Причина смешная: GET /users отвечает девять секунд. В таблице 31 412 пользователей, из них 31 380 с почтой вида user_qXwTbRkL@antrakt.test. Это ваши тесты. Они вообще за собой убирают?

Вера Ланская · лид QA, #qa-antrakt

По коду убирают: в created_user после yield стоит DELETE. Значит, удаление либо не вызывается, либо не работает, и никто этого не видит. Разберись, откуда мусор, и сделай так, чтобы тестовые данные жили ровно столько, сколько нужны тесту.

В прошлом уроке мы проверяли, как API отказывает. Сегодня вопрос с другой стороны: всё, что тест создал на стенде, остаётся там после теста. Пользователи, заказы, промокоды. Если за ними не следить, через месяц стенд превращается в свалку, а тесты начинают мешать друг другу. Разберём жизненный цикл тестовых данных: как создавать, как убирать и что делать, когда убрать нельзя.

Опись реквизита

Перед спектаклем реквизитор раскладывает на сцене чашки, письма и шпагу. После спектакля всё это надо убрать: завтра на этой сцене другая постановка. Реквизитор работает по описи. Что выдал, то вписал. Что убрал, то вычеркнул. Если в конце вечера в описи осталась строчка, он идёт искать чашку, а не надеется, что её кто-то унёс.

Тест на общем стенде работает как реквизитор. Он создаёт данные под себя, проверяет на них поведение и должен вернуть сцену в исходное состояние. Тест Глеба выдавал реквизит без описи и уходил домой, не глядя, убрано ли.