Указанные зависимые тесты для апи, конечно же дно, и с Vita я не соглашусь. Единственное хорошее что есть в зависимых тестах — это экономия времени.

Что касается тестов апи, то в современном мире 95/100 http интерфейсов - это rest. У него нет стейта, что значит ты не хочешь завязываться на тестировании этих сущностей как цепочки. Скорее наоборот, правильнее готовить нужные тестовые данные (доставать из базы) и в изоляции методы проверять

Проверяешь что пользователь который оплатил подписку имеет доступ к получения списков фильмов в библиотеке ? Найди пользователя с таким статусом из базы, не нужно отправлять апи запрос на оплату подписки

Ох.... Насчёт БД с их uuid и сложными полями мне проще создать! Но да, лучше уж в БД лезть в тестировании API

Есть один параметризованный тест, я хочу отдельно запускать часть из этих тестов, можно ли как то промаркировать их? python pytest

Привет. Если уже было, не ругайте и ткните пальцем.
Есть веб админка, pytest, selenium. Чтобы попасть на любую страницу, нужно сначало залогиниться. Вспоминая принцып про не зависимые тесты, получается, что надо в каждом тесте снова логиниться через UI?
Я вынес логин в отдельную фикстуру, где додаю кукис драйверу для данной тест сессии. Но теперь получаеться что все тесты связаны между собой по куки?
Подскажите как правильно решить такого рода задачу. Спасибо!

связаны так же как и драйвером?

Да..

я конечно не профи, но вроде это ок. они же друг от друга не зависят

Насколько я помню, только если параметризовывать кастомно как-то, или выделять еще одну сущность-тест и ее уже по тэгам раскидывать

В целом - норм.
Однако никто не мешает обрывать сессию через API, получать новые куки и тестить еще больше независимо.

Тут на вопрос больше не в том, как лучше, а нужно ли оно вам? Может быть там хрупкость возрастет неаероятно, или чтобы корректнр стабилизировать эти вещи с ui+api нужно много времени, которого у вас нет?

Кратко: норм.
Стремимся к все большей независимосии.

Спасибо! api - смесь soap с rest - убогое очень

Я недавно задавал здесь вопрос по поводу подложки под тесты и помощь себе в них. Ответ был следующий: обычно создает контекст на 1 уровень ниже для вспомогательных вещей.
То есть если тестируешь UI, напиши также контекст к API.
Если API, то к базе данных.

Хорошо, возьму на вооружение

Подскажите, плз
Как сделать фикстуру которая будет отрабатывать только если тест passed(ассерт вернул True), а если тест фейлится (ассерт вернул False), то возвращать информационное сообщение.
Это через хуки как-то делается?
Пример:
Есть тест в котором дергаем эндпоинт, он создает заказ. Если в ассерте True, то иду в базу и удаляю заказ,  если нет, то ничего не трогаю.

Хотите сэкономить трафик в случае падения теста? Зачем там логика? После каждого теста удалять и всё.

А зачем привязываться к тесту? Удаляй на похуй. Создаст сущность тест - значит удалит нужную инфу. Если нет,  то ничего не произойдёт

Как будто база упадёт, если удалит то, чего нет лол

А если тест упадёт не на ассерте, а где-нибудь после создания, но до ассерта? Тогда удаления не будет, и созданный объект останется в базе.

тема такая что у меня в тесте так и есть щас - прям беру из респонса данные для удаления и в тесте хожу в базу и удаляю, если нет, то соответственно ничего не делаю,потому что удаление после ассерта идет следом.
Но вот на ревью мне говорят что нужно в yield фикстуру выносить и я чет не вдупляю как это тривиально делается.

@pytest.fixture(autouse=True)
def cleared_db():
   yield
   
   db_steps.delete_all(table_name)