Как получить ID созданного товара в тесте для его удаления в постусловиях?
Что проверяют
Понимаете ли вы, что постусловие должно выполниться даже при упавшем тесте, и умеете ли протащить ID из шага создания в этап очистки. Следом обычно спрашивают, что делать, если товар создавался через интерфейс и ID в тесте не виден, и как чистить данные при параллельном прогоне.
Как отвечать
Сначала откуда взять ID:
- ответ API: POST на создание обычно возвращает объект или заголовок
Location. В Python этоresponse.json()["id"], в REST Assured.extract().path("id"), в Postmanpm.collectionVariables.set("productId", pm.response.json().id); - создание через UI: перехватить сетевой ответ (в Playwright
page.expect_responseс фильтром по URL), взять ID из адреса после редиректа на карточку или изdata-атрибута; - поиск по уникальному признаку: в название кладут
uuid4()или префикс прогона, а ID потом находят запросом к API.
Потом как гарантировать удаление. В pytest это фикстура с yield: до yield создание, после него удаление, и эта часть выполнится при любом исходе теста. Если товар создаётся внутри самого теста, используют request.addfinalizer или фикстуру-реестр, куда тест складывает ID, а teardown удаляет всё накопленное. В JUnit 5 ту же роль играет @AfterEach, в unittest addCleanup.
Удаление в teardown делайте терпимым: ответ 404 значит, что товар уже удалён, и тест из-за этого падать не должен. На случай прерванных прогонов держите отдельную зачистку по префиксу, которую запускает CI.
Где спотыкаются
Пишут удаление последней строкой теста. Первый же упавший assert оставляет товар в базе, и через неделю стенд забит мусором, который ломает чужие проверки.
Хранят ID в общем поле класса. Если тест упал до создания, teardown удалит объект предыдущего теста по старому ID, а при параллельном запуске в потоках тесты перезаписывают значение друг другу.
Удаляют прямым SQL в обход API. Так легко оставить висячие связи, остатки на складе или записи в поисковом индексе, а тест начинает зависеть от схемы базы, которая не входит в его зону.