Комментарии 38
Да вроде бы оригинальная документация на оф сайте и так объясняет все что нужно.
Ещё не понял зачем в классы объединять тесты?
Эта магия с созданием атрибутов через request фикстуру выглядит не дружелюбно к чтению. Нужно ещё догадаться откуда оно там пришло, не проще ли передать в нужный тест фикстуру login, как параметр функции? Так бонусом ещё и легко указать тип для значения фикстуры что важно, так как в современном питоне принято использовать аннотации типов.
Обьясняет, да, только так, что любой новичок впадет в шок)
Вопрос 1 - Тесты обьединяются в тестовый класс (это тестовый сьют для pytest) + как сказано в начале статьи, используется паттерн PageObject
Вопрос 2 - Как написано в статье, магия с request это один из вариантов использования, о котором необходимо знать, к примеру для того, чтобы не прокидывать драйвер во все тесты в качестве аргумента
Вопрос 3 - Касательно к примера с тестовыми данными, да, несомненно проще прокидывать фикстуру в качестве аргумента в тест
Вопрос 4 - Про аннотации типов согласен, но их даже многие крутые разрабы не используют, а для новичков это лишние сбивающие с толку каракули в коде, а моя задача ясно изложить суть фикстур)
Спасибо большое за комментарий)
Тесты обьединяются в тестовый класс (это тестовый сьют для pytest) + как сказано в начале статьи, используется паттерн PageObject
Я вижу что они в классы объединены, я не понял зачем, так как пайтест парадигма как раз в том и заключается что ты пишешь атомарные тесты, там нет наследований как в юнит тестах всё постороенно на функциях и декораторах.
Ваш ответ
Как написано в статье, магия с request это один из вариантов использования, о котором необходимо знать, к примеру для того, чтобы не прокидывать драйвер во все тесты в качестве аргумента
Противоречит следующему
Касательно к примера с тестовыми данными, да, несомненно проще прокидывать фикстуру в качестве аргумента в тест
Не вижу ничего плохого прописывать в каждый тест аргумент функции.
Про аннотации типов согласен, но их даже многие крутые разрабы не используют, а для новичков это лишние сбивающие с толку каракули в коде
Эм что это за крутые разрабы которые в современном питоне не используют типы? Может они и тесты не пишут? А то знаете какие то портянки кода не нужные.... Без типов и их статической проверки, если он сложнее одного файла, ваш код превращается в мишуру, которую приходится разгадывать в рантайме.
Если вы разработчик и не знакомы с направлением QA, и работали только с unit тестами, то статья не для Вас, она для QA! Но в целом почитайте про PageObjectModel (паттерн для автоматизации тестирования) это сфера QA. Тесты и так атомарные, там нет никаких наследований в коде.
Зачем прописывать каждый раз драйвер?) Вам что крутой автоматизатор, что ChatGPT абсолютно такую же инициализацию драйвера через фикстуру сделает, как меня в примере)
И снова, я убрал все лишнее чтобы сконцентрировать внимание QA Automation инженеров на определенной теме, а не фронтендеров, бекендеров, девопсов, если вы так негативно реагируете на отсутствие аннотаций, напишите лучше статью на эту тему, и задумайтесь сколько лет писали и без нее и никто не умер☺️)
Ну и поверьте, чтобы изучить фикстуры, да и в целом любуууууую тему, по умолчанию знать аннотоцаии не является ни блокирующим, ни обязательным условием!
Если человек не знает аннотаций, это не значит что он не имеет право учить что-то без них)
Фикстура - это превращенная в декоратор функция
А что декорирует фикстура?
Тесты) Говорю про это когда обьясняю yield))
Как обычная функция ничего не принимающая, например, и просто возвращающая значение вдруг превращается в декоратор?
Из статьи:
Для того, чтобы функцию зарегистрировать как фикстуру, в pytest есть специальный маркер @pytest.fixture, который нужно прописать над нужной функцией.
Открою секрет - вот этот вот самый маркер и есть декоратор, а yield это вообще про генераторы.
Ну это не секрет) Если говорить глубже, то да маркер = декоратор, по сути этот маркер декоратор превращающий в декоратор принимающую функцию) И yield в контексте pytest никак не связан с генераторами) Не путайте со стандартным yield из Python
Рекомендую ознакомиться в целом с pytest и PageObjectModel паттерном.
Тут в оф документации https://docs.pytest.org/en/latest/how-to/fixtures.html можете найти информацию и про тестовые классы и про yield)
А вы доку хоть открывали? Где там упоминание, что pytest превратился в самостоятельный язык программирования, который по своему трактует ключевые слова python?
Сомневаюсь, судя по вашей статье, что вам это поможет, но все же глянтье: https://github.com/pytest-dev/pytest/blob/main/src/_pytest/fixtures.py#L893-L922
PS Причем здесь тестовые классы и POM?
Я бы мог ответить, что судя по вопросу "зачем тесты обьединять в класс" все понятно, но к сожалению не вижу смысла обьяснять что-либо негативно настроенным людям, значит статься поможет кому-то другому)
Кратко поясню, есть контекст, в рамках фикстур yield выполняет функцию пред- и постусловия, и да, я читал официальную доку)
Вот ответ для Вас из нее, если владеете английским вероятно поймете:
“Yield” fixtures yield instead of return. With these fixtures, we can run some code and pass an object back to the requesting fixture/test, just like with the other fixtures. The only differences are:
returnis swapped out foryield.Any teardown code for that fixture is placed after the
yield.
Once pytest figures out a linear order for the fixtures, it will run each one up until it returns or yields, and then move on to the next fixture in the list to do the same thing.
Once the test is finished, pytest will go back down the list of fixtures, but in the reverse order, taking each one that yielded, and running the code inside it that was after the yield statement.
Я, вообще, про классы ничего не писал) Таааак... Доку читали, уже не плохо. И где там говорится что yield не превращает функцию в генератор? Все что написано в доке этому никак не противоречит и сорцы pytest это как раз и подтверждают. Учите матчасть)
Про классы пардон, не ваш вопрос, моя вина, ошибки признавать умею) Я понял о чем вы, только вот в чем суть, после прочтения моей статьи автоматизатор, особенно юнный, сможет легко зайти и использовать фикстуры на полную, даже не парясь о том, что такое генераторы. В рамках тестирования и написания фикстур, вот вообще все равно генератор это или нет. Для тестирования это разделитель пред и постусловия.
Пример: Как вы поступите с ребенком, когда он Вас спросит, как ездит машинка?
Наверное Вы ребенку скажете, что вот баранка, если ее крутить, то машинка поворачивает, если жать на педальку она едет.
В данной ситуации, ребенку важна и полезна только эта информация, а не та, где вы начнете говорить, что машина поворачивает, потому что передается крутящий момент на оси колес или машина едет потому что в ДВС работают поршни, туда впрыскивается бензин, и посредством его сгорания и т.д...
Да и в реальной жизни, вот мне пофигу как машина едет, мне достаточно верхнеуровневых знаний, и поверьте, если вы о машине знаете все глубже, от этого я или другой человек водить хуже чем вы не будет)
С образовательной точки зрения, я считаю моя статься несет море полезной информации.
В целом, спасибо за комментарий, статься написана как раз для людей, а не мат батанов и программеров с 100к + лет стажем)
Наверное Вы ребенку скажете, что вот баранка, если ее крутить, то машинка поворачивает, если жать на педальку она едет.
Если ребенок уже знает, что баранка это съедобное изделие из муки, то у него тоже возникнет когнитивный диссонанс. Вам придется дополнительно рассказывать про шоферский жаргон. Что в целом усложняет задачу обоим: вам объяснить, ребенку - понять. Разве не проще сказать, что крутить нужно рулевое колесо?
В остальном про пред и пост условия полностью поддерживаю.
В статье как раз и говориться о рулевом колесе, жаргонов там вы не найдете)
В целом, спасибо за внимание к статье и за дискуссию)
Я не могу сказать что Вы не правы, отчасти правы, но скажу однозначно, обьяснить на пальцах без заумных фраз чаще на много полезнее и эффективнее, чем грузить терминологией, которая может оттолкнуть человека.
Уметь программировать и учить, доносить информацию так чтобы ей могли пользоваться, это разные вещи)
Ну и важно помнить, нет единого пути, собственно в статье я представил свой, и уверен, он точно кому-то поможет)
Ребенку, в отличии от юного автоматизатора, не надо будет общаться с коллегами и проходить собеседования)
Отрицание, верный признак негативного восприятия всего и вся)
Поверьте, этого более чем достаточно чтобы ответить на все вопросы, человек идет на автоматизатора, а не разработчика бекенда!
Я проходил очень много собеседований, получал офферы в очень хорошие компании, как и вы скорее всего (в хорошем смысле) и меня более чем отлично понимали!
Судя по тому что Вы разработчик, говорить нам особо дальше не о чем, предположу, что вероятно специфику собеседований и знаний для автоматизатора вы не совсем знаете.
У вас свой опыт, у меня свой, и косвенно утверждать что ваш опыт это эталон такое себе.
Если Вы не поймете, сотня других автоматизаторов поймет)
Ну и поверьте, если люди дошли до темы фикстур, они явно не идиоты, уж смогут обработать информацию и сформулировать для себя поинт
Но еще раз скажу спасибо, любое мнение имеет место быть?
Ну и в названии статьи напомню «На человеческом», не на прогерском, математическом или еще каком-то языке)
Очень сильно не хватает такого рода обьяснений!
В целом-то неплохая статья получилась, я прочитал с интересом. Но неверное использование терминологии никогда не идёт на пользу делу, лишь сбивает с толку. А кроме того, портит впечатление от текста и вызывает недоверие к автору. Аудитория Хабра привыкла к точности формулировок. Большинству людей, имеющих дело с кодом, просто больно, когда фикстуру называют декоратором, декоратор маркером, оператор return методом, а yield — функцией.
Вот это адекватная, без негативная критика, вызывает уважение!
Я вас понимаю, сам использую терминологию в работе, некоторые моменты в статье поправлю, спасибо!
Если говорить в целом, автоматизатор, даже продвинутый, имеет явно меньше опыта с кодом, и многие термины могут быть не понятны, опять же, QA Automation, после этой статьи пойдет и напишет тест используя фикстуры и принесет пользу компании и постепенно будет углубляться в другие темы, а не пойдет читать про аннотации, про генераторы и прочее, не принеся никакой пользы в итоге
В конечном же итоге, можно всю жизнь изучать как устроен автомобиль, но ни разу не сесть за руль) Думаю тут сложно не согласиться
Думаю тут сложно не согласиться
В свою защиту вы пытаетесь выставить автотестеров какими-то дремучими. Может такова политика у вашего работодателя или ещё какая-то особенность. Со стороны эти упражнения в риторике и тщетные попытки продать читателям баг как фичу выглядят нелепо. Если вы профессионал, уже сто раз могли набраться мужества и все поправить.
Последние несколько лет часто работаю с QA (индусы в основном) потому, что они знают продукт подчас лучше BA и разработчиков. Иногда про себя упрекаю в дотошности, но ни разу не замечал безграмотности. Они сами меня периодически поправлют когда говорю что-то не правильно.
Насчет return опечатался, исправил спасибо) yield - в статье я функцией не называл)
Так же поправил определение фикстуры)
Спасибо за продуктивную и не негативную критику) На сколько я вижу, некоторые люди негатив считают продуктивной критикой)
Да, не. Желание объяснить понятным языком понятно. Но тут, как выше заметили, в результате местами получился какой-то сюр. Видимо у вас там какой-то местный жаргон, раз называете фикстуры декоратором. Но со стороны выглядит феерично. Всё таки в статье на широкую аудиторию лучше назвать вещи своими именами.
что позволит запускать тесты параллельно
Ну, все-таки без плагина xdist или подобного параллельно запускать не получится, тесты в классе (или в модуле) исполняются последовательно, в порядке объявления.
Еще один текст в жанре школьного изложения. Для публикации непригодно. При этом автор еще и от замечаний отбрыкивается. В качестве альтернативы рекомендую Brain Okken "Testing with pytest".
Спасибо за статью! Может местами не очень точно, но определенно на человеческом языке)
Всё таки наверное правильнее было бы поставить scope в другом порядке по важности:
function - инициализируем предусловия для конкретного теста, выдаем специфические тестовые данные и т.д. В идеале, если стремиться к атомарности тестов, для каждого теста можно бы и браузер отдельный запускать средствами, например selenoid
session - привести стенд в исходное состояние, создать тестовые данные, подключиться к БД и очень много других действий, которые не имеет смысла выполнять больше одного раза за прогон
class - для каких-то специфических операций для конкретного тест-сьюита
Буду рад узнать, если я вдруг не прав)
Статья для новичка кмк хорошая, но как минимум нет фабрик, а это очень нужная вещь. Иначе джуны начинают плодить методы с передачей всего подряд в качестве аргумента либо просто копипастить код "потому что нужно больше одного объекта"
Pytest-фикстуры на человеческом