Как лучше реализовать удаление товара: этапом теста или фикстурой?
Что проверяют
Различаете ли вы действие, которое тест проверяет, и действие, которое просто прибирает за ним. Ответ «зависит от того, что проверяем» здесь правильный, но только если сразу назвать критерий. Следом обычно спрашивают, что станет с данными, если тест упадёт посередине.
Как отвечать
Критерий простой: если удаление товара и есть проверяемая функциональность, это шаг теста с проверками. Если удаление нужно, чтобы не оставить мусор после теста про карточку, корзину или поиск, это очистка, и её место в фикстуре.
- удаление как шаг: тест получает товар (лучше через API или фикстуру, а не через UI), удаляет его, проверяет ответ (
204или200), затем проверяет, чтоGETвозвращает404, товар пропал из списка и поиска, а связанные сущности вроде корзин обработаны по правилам; - удаление в фикстуре: в pytest фикстура с
yieldсоздаёт товар и отдаёт его тесту, а код послеyieldвыполняется как teardown даже при упавшем тесте. В Playwright Test то же дают собственные фикстуры с кодом послеuse()или хукafterEach; - устойчивый teardown: очистка не должна падать, если тест уже удалил товар сам. Удаление, которое считает
404нормой, избавляет от ложных ошибок; - область видимости:
scope="function"даёт каждому тесту свой товар и независимость,scope="module"или"session"экономит время, но тесты начинают влиять друг на друга.
Сильный ответ совмещает оба подхода: в тесте на удаление товар создаёт фикстура, а сам тест проверяет удаление. Фикстура при этом подстраховывает очистку на случай, если тест упал раньше шага удаления.
Где спотыкаются
Удаляют последним шагом теста без фикстуры. Стоит упасть проверке раньше, и в базе остаётся мусор, который ломает соседние тесты.
Прячут в фикстуру то, что проверяют. Если удаление живёт только в teardown, его поломка покажется как ошибка очистки, а не как упавший тест, и её легко проигнорировать.
Удаляют через UI в каждой фикстуре. Это медленно и хрупко, для подготовки и очистки данных надёжнее API или прямой запрос в базу.