Backend и API - Создание проекта (фреймворка) по автоматизации тестирования на Python

[@АркадийНалимов-р1э]

Спасибо дяденька, максимальный респект

[@Evgeny_89]

Евгений, спасибо! Такое небольшое, но очень полезное видео! Заставило меня немного подправить свои тесты:) Успехов!

[@luckytima2315]

Спасибо, наши мольбы услышаны)

[@SeniorTester]

Просто очень хорошо и громко молились )))

[@ТуТа-л8и]

Волшебно!

[@SeniorTester]

🤟

[@vladberezovskiy7031]

Спасибо очень классный формат, быстро и понятно! Надеюсь что скоро выйдет видео, в котором ты до конца усовершенствуешь этот проект по апи!

[@redazaki297]

спасибо! ты лучший!

[@SeniorTester]

😂

[@vladshambaryan8852]

Спасибо Женя. Я пошёл смотреть твоё видео про классы.

[@klimtro]

спасибо, Евгений. вцелом удобно! пэйджи применять при тестировании апи же нельзя, поэтому обертка в классы выглядит хорошим решением

[@zubescu]

спасибо. очень доходчиво объясняешь.

[@SeniorTester]

Спасибо, стараюсь

[@johndeere4726]

очень полезное видео! помогло разобраться

[@fimasmf4444]

По видео вопросов нет. Четко, понятно. Шик! Если будет возможность и желание, добавить видео по тестированию API с использованием mock. По коду, позволю такое замечание: все сходят с ума по части PageObject и ООП, штуки хорошие, нужные, знать обязательно надо. Другое дело, понимать как и где это нужно применять. В начале делал похоже, как в видео. В итоге в тестах оставалось пару строк. Красота. Потом столкнулся с тем, что другим приходилось обширно шариться по всему проекту, что бы дебажить и понимать в какой функции, есть косяк. Не удобно. В итоге пришел к тому что, есть отдельный файл с функциями, которые как по шагам собираются в тесте. В качестве ООП, работают аргументы, которые позволяют полиморфировать функцию если надо. В итоге вообще ушел от классов. Только фикстуры и параметры. Повторюсь - это, лично мой опыт. Тут нет правильного решения, есть только удобное. Для конкретного человека или проекта. За видос все равно респект.

[@SeniorTester]

Да, отличная поправка на то, что для каждого проекта нужно использовать то, что подходит. По сути, здесь я показываю классический подход, знание которого необходимо. Подход с функциями построить проще. Но странно, что вы столкнулись с проблемами в поддержке такого. ООП как раз и создан для упрощения процесса поддержки. Каждая вещь в одном месте. В любом случае, за коммент и мнение спасибо

[@fimasmf4444]

@@SeniorTester Я возможно не точно выразился. Попробую иначе. При падении теста, когда все упрятано в класс, нужно идти в него, потом в функцию, потом проверять все ли норм будет с асертами и т.д. потом обратно возвращаться в тест. А когда отдельная функция, без привязки к классу, но которая работает в любых тестах - получилось быстрее и главное понятнее для других. Из минусов, чуть больше повторяющегося кода и чуть больше текста данных в тесте. Опять же, не всегда необходимы объекты.

[@АртемКурто-м5ч]

Спасибо. А как быть с тем, что у нас проверки проходят не в тесте, а в отдельном файле? И когда тест падает мы получаем в терминале ошибку assertion error без указания expected_result и actual_result. А если ассерт перенести в сам тест, то выглядит читабельней.

[@ПростоКоляка]

Хороший вопрос, потому что я его тоже себе задавал и решил сделать следующее: создал класс BaseAssertationMessage, который инициализируется 3 сущностями: text_message, exp_res, act_result. Собственно потом этот класс можно прокидывать после ассертов как сообщение (__repr__\__str__\__call__). Для ассертов, связанных с респонсами релиазовал отнаследованный от базового класс, куда дополнительно нужно класть респонс, а из него в ассерт сообщение выводить параметры запроса и сам респонс в виде json или текста. Теперь в чем преимущество инкапсулировать проверки в методы класса: так ассерт сообщения (с вышеупомянутой реализацией) выглядят чистыми, понятными и легко поддерживаемыми. Однако, если ассерты впиливать в сами тесты, pytest реализовывает свою логику ожидаемого и фактических результатов, что не всегда читаемо, плюс их реализации приоритетна и кастомные сообщения могут быть обрезаны, даже в алюррепортах ) В общем, инкапсуляция проверок - это хорошо. А ассерты внутри самих тестов, скорее, больше подходят для легеньких юнит-тестиков )

[@user-els1z6htp7]

Расскажи, пожалуйста, про тестовые данные и варианты реализации)

[@MichioSempai]

Вопрос. Если на проекте есть openapi, имеет ли смысл использовать его для генерации клиентов и его использовать в тестах? Из недостатков я вижу следующее, в сгенерирлванном клиенте есть много проверок на саблюденте контракта, что не позволит нам нам писать негативные автотеств где это контракт и не соблюдаются

[@frankiew6576]

Тема актуальна, спасибо за идею, но хотелось бы видеть не просто код, а и то как он работает

[@SeniorTester]

Как оно работает я показывал в предыдущем видео. Решил не затягивать. Разницы в запуске нет

[@MrSprit797]

Здравствуйте, спасибо за видео, вот бы ссылку на репу, что-бы сразу взять за костяк на своих проектах. И да ждём видео куда прятать тестовые данные.

[@VzhikIn]

Привет 👋🏼 сделай видос «N способов, как хранить payloads” 😉

[@markuschris5813]

Евгений, здравствуйте! Можете ли вы выложить ссылку на проект, который реализован в видео?

[@stanislav_laptenok]

Привет, очень классное видео, как ты и говорил, пишу тебе с просьбой что бы ты рассказал, где хранить dict для payload , и как вытягивать данные для assert , я думаю очень многим это будет очень полезно, заранее спасибо, надеюсь у тебя есть силы для данного видео.

[@SeniorTester]

С тестовыми данными запрос понял. А что значит "вытягивать данные для assert"?

[@stanislav_laptenok]

@@SeniorTester окей, попытаюсь объяснить, вот например отправил я файл в чат , и мне нужно сделать проверку по названию файла , что с Бэка мне приходит точно такое же название файла как я и отправлял , первую часть я возьму с респонсе для для проверки , это что мне пришло , а вот я допустил создал отельный файлик с тестовыми данными и для сравнения у меня не получается от туда взять название файла , так как передаётся полный путь к файлу , а не название файла , так вот хотелось бы посмотреть как ты это реализуешь, может я вообще не правильно делаю , надеюсь моя мысль после этого стала , немного понятна)

[@mironpentasteal39]

видосики полезные и классные, спасибо! а такой вопрос: а почему ассерты выносятся в класс, разве они не должны быть непосредственно в самих тестах, притом только в единственном экземпляре? а то тут идет проверка и статус кода, и еще чего-то, помимо этого. и если есть какая-то тонкая грань между "можно совмещать несколько ассертов одновременно" и "это уже разные тесты должны быть", то где она?

[@ПростоКоляка]

Привет, я попробовал ответить на твой вопрос в комментах выше, как это мне видится )

[@КириллСолнцев-й5д]

Хорошоее видео, молодец. А если в каждом тесте идет проверка на status 200. Как эту проверку сделать общей для всех тестов, чтобы не прописывать в каждом?

[@SeniorTester]

Если заморочиться, то можно, но зачем? Ведь это шаг теста, пусть он будет в тесте. Иначе, тест будет выглядеть неполноценным

[@evi1ive]

Лайк + подписка

[@SeniorTester]

Всё правильно

[@Максим-г1ч1в]

Сделай проект по тестированию бд постгрес (проверки качества данных и всякое такое)

[@SeniorTester]

У меня в голове где-то есть понимание как это в принципе будет выглядеть, но на практике я таким не занимался. Базой данных обычно пользуюсь только или для получения данных, которые нужны для тестов или для изменения каких-то состояний, которые проще изменить через базу. Так что, не думаю, что такое от меня будет полезно.

[@ПавелЩелоков-ш7е]

а как же baseApi класс а прикрепление шагов в allure?

[@SeniorTester]

И вынесение данных И base_url И моки И параллельный запуск И параметризация И взаимодействие с БД И интеграция с ТМС И запуск из CI/CD Мелочей и деталей хватает. Всё постепенно будет появляться, в одно видео это не уместить.

[@akseley335]

Здравствуйте, а что описывается в baseApi классе?