Да, тесты пишем именно таким образом. Отличие в том, что сама структура тестов более сложная, в статье много было опущено, + мы используем async await для всех тестов API и UI.
Тестов достаточно много, 3000+ API тестов. Поддерживать с таким подходом просто, гораздо сложнее поддерживать было ранее.
Я пришел к данному подходу спустя несколько лет разных проектов, разных компаний, разных команд (от 1 QA Automation на 1 проект, до 5-7 QA Automation в одной команде). Куда бы не попадал, везде были похожие проблемы, похожие решения. Потом я изучал очень много данных по автоматизации тестирования, это были, как русскоязычные, так и англоязычные ресурсы. После нескольких лет практики, я вывел одну важную вещь: даже если компания крупная, даже если там большая команда QA Automation и большой продукт, это не мешает QA Automation инженерам изобретать велосипеды. Ну или в компании может быть главный "велосепедист") Такого человека еще в шутку называют "Хранитель говнокода") Обычно это QA Automation, который пришел в команду раньше всех и почти весь фреймворк написал он, ни в коем случае не хочу никого оскорбить, просто так бывает
1. Сначала мне хотелось решить проблему с типизацией в автотестах. Изначально все выглядело так
Но мне ни первая, ни вторая записи не нравились. + В команде менялись люди, кто-то уходил на другой проект, потом брали новых QA Automation, иногда это были даже джуны. Часто случалось так, что тот человек, который писал этот код уходил из компании и уже было сложно понять, что же там написано. Усложнялось тем, что не на всех проектах был сваггер и документации по API не было, как правило это компании стартапы, которых сейчас не мало. Даже если сваггер был, то ходить каждый раз в сваггер было не удобно + шанс запутаться был только выше.
Потом на помощь пришли dataclass-ы. Которые +- решили проблему с типизацией. Но сразу же появились проблемы с тем, чтобы конвертировать модель dataclass-а в json/dict, генерировть схему. Тут на помощь пришла либа dataclasses-json, которая делает +- тоже самое что и pydantic, где-то криво-косо, но на тот момент было хорошо. Но в текущих реалиях, я 100% отдаю голос за pydantic, у него намного больше фичей, чем у dataclasses-json.
2. Еще была проблема с json schema. Ее хардкодили, автоматически схему никто не генерировал. Мне тоже это не нравилось т.к. в проекте было ну очень много enum-мов, со всякими статусами, кодами, было много сущностей, у которых было поле type, которое было enum-мом. Обычные сайты по типу generate json schema online могут сгенерировать схему для простого объекта, но они не учитывают что какое-то поле не просто striing, а 'enum': ['started', 'finished'].
Из-за хардкода схемы приходилось делать в два раза больше работы. Если разработчики обновили type какой-то сущности, то нам нужно было обновить enum в автотестах + переписать схему руками, ведь online генератор в этом не поможет. + Иногда люди криво писали схему и совсем забывали, что поле не просто integer, а какой-то конкретный enum.
Эта проблема решилась вместе с dataclass-ми + либа dataclasses-json. Всю хардкоженную схему убрали. Теперь при изменении enum-ма схема автоматически обновлялась, т.к. генерировалась автоматически.
Наверное тут можно было бы сказать, что эту проблему можно было бы решить автоматически через генерацию клиента на основе swagger. Да, согласен, если у вас есть ресурсы и время, на написание скриптов для генерации клиента. Но на практике именно для python я не видел таких скриптов, только для Java.
3. Лично мой выбор, это отказ от requests в пользу httpx. Потому что сейчас все пишем через async await, ну и философия библиотеки httpx мне больше близка. Но requests тоже очень даже хорошая либа
В принципе SearchModal можно наследовать от BasePage, при необходимости. Но как по мне Components не должны наследоваться ни от кого (если только нет родительских компонентов).
Например если мы говорим про модальное окно логина, которое предлагает нам войти в систему, то это Component. Поля ввода, кнопки, иконки в этом модальном окне будут считаться, как Page Factory. Модальное окно логина, может быть использовано на разных страницах, поэтому мы выносим это в отдельный слой - Component. В автотестах мы сможем использовать этот Component на разных страницах, например DasboardPage, FormsPage, ProfilePage и т.д. нам будет достаточно использовать композицию и не дублировать код. Page Factory же поможет нам, удобнее работать с элементами внутри модального окна логина.
Рад, что статья оказалась полезной. Давайте по вопросам:
Да, такой вариант тоже возможен Модель.parse_obj(ответ), вполне. Для моделей у которых несколько разных типов полей можно использовать объединения. Например у нас есть JSON объект, в котором есть поля {"id": 1, "state": 1}. Поле "state" может быть строкой, числом, списком из чисел. Тогда модель будет выглядеть так
Для python 3.10+ эта запись может быть другой, например state: str | int | list[int]. В итоге при генерации схемы мы получим поле state в таком формате
В данном случае поле state является anyOf string, integer, array + items integer. То есть все эти JSON объекты будут валидны
Таким образом, мы можем описывать разные типы полей. Надеюсь я правильно понял ваш вопрос
Ну тут нужно смотреть индивидуально ваш продукт. Не смогу сказать точно, как это сделать именно для вашего проекта, т.к. мне нужно будет знать много пунктов. Вот, что можно предпринять: 1. Выбрать правильную структуру для моделей. Например у нас есть сервисы users, grading, payments Тогда раскладываем модели так: models/users/user.py models/users/auth.py models/users/emails.py
Это должно решить проблему с запутанностью. Понятно, что у вас скорее всего структура будет намного сложнее, но суть к остается та же. Если раскидать модели по правильной структуре, то мы сможем всегда знать, где находится нужная нам модель.
2. Если же у вас ситуация по типу, когда внутри одного и того же объекта могут быть разные модели, например
То в таком случае, чтобы не писать каждый раз новую модель и не дублировать код, можно воспользоваться Generic моделью
В таком случае T будет динамически заменяться на тот тип, который вы передадите. Это поможет избежать дублирования кода, если внутри какой-то общей/глобальной модели используются разные модели из других сервисов.
Возможно дополнительный слой нужен. В примере с questions я писал два метода
create_question_api create_question
Внутри create_question хорошо было бы добавить проверку, черед тем, как прокидывать response.json() внутрь модели, то есть:
Тогда в случае ошибки мы упадем раньше, чем попадем в модель.
Можно поступить по другому, в pydantic есть такая киллер штука, как ValidationError, с помощью нее, мы можем сформировать очень даже читабельное и понятное сообщение об ошибке в отчете. Например нам из API пришел пустой объект, тогда мы можем попробовать спарсить его и если что-то не так, то кинуть сообщение об ошибке
Фишка тут в error.json(), эта ошибка будет выглядеть примерно так
Что +- можно прочитать и понять, что именно было не так. Дальше уже вопрос в том, как вы это будете применять. Можете написать обертку, которая сначала будет пытаться запихнуть json в модель, если не получится то выбросит ошибку в json формате. JSON формат ошибки можно настроить или отформатировать, как вам удобно
Да, можно промисы через then, catch, это ведь тоже самое, что и async/await. Тут вопрос только в том, как мы это используем. Кто понял, тот понял)
Когда фронтенд разработчики пишут приложение, у них есть понятия screen/page, module/component. То есть страница (Page) состоит из компонентов (Component), компонентами могут быть, модальные окна, формы, карточки, лист айтемы, и т.д. Page Factory это больше про то, как мы работаем с локаторами. В Page Factory мы оцениваем локатор, как какой-то конкретный объект или свойство. Ну если привести пример из жизни, то все элементы это конструктор lego, Page - это собранная модель, Component - это отдельные части, рука, нога, голова, Page Factory - это сами детальки lego)
Преимущества описывал выше, в разделе "Page Factory", посмотрите, там достаточно много пунктов и подробно описано. Возможно это не классическое представление Page Factory, но единственное рабочее для моих целей, цели я тоже описал
Да, прикольная фича, возьму на заметку. Я привык писать на python, там такой возможности нет
typeOf переопределяется для отчета, в отчете будет видно с каким объектом мы работали. То есть Click on button(typeOf) with name "Hello", Click on input(typeOf) with name "Some"
typeOfUpper - возможно да, но вам стоит помнить, что эта статья не туториал. Я не пытаюсь рассказать людям как писать супер правильный TS код, мне больше интересно показать, как лучше писать UI авто тесты.
Чтобы динамически обработать и сгенерировать нужный нам локатор и только потом использовать объект локатора в методе
Чтобы уникализировать методы работы с объектами на странице. Я приводил пример выше с .toBeVisible(), .isVisible(), оба метода выполнят задачу, но правильный по сути только один. Да, на hover это не распространяется, тут этот пункт работать не будет
Если вы тестируете продукт, в котором есть специфические компоненты, например для hover на такой компонент, необходимо сначала кликнуть куда-то, ну или в этом духе. Тогда можно делать кастомные компоненты, например MyCustomButton, внутри реализовывать именно тот hover, который будет кликать, а потом делать hover. Ну это чисто пример, на практике разное бывает
Да, нужен читабельный шаг для отчета. По дефолту playwright делает шаги, но они не отражают бизнес логику, которую мы тестируем. + Как показывает практика, manual qa и менеджерам очень сложно читать дефолтные шаги от Playwright, они не информативны
Приятно слышать, что кому-то материал оказался полезен)
По поводу комментариев, абсолютно с вами согласен. Критиковать кого-то намного проще, чем похвалить, для критики или хейта даже слова легче подобрать, нежели для положительного фидбэка
Я бы сказал так, что документации в виде типов будет достаточно для понимания. Но еще бы хотелось, чтобы на основе авто тестов генерировалась тестовая документация, то есть тест кейсы. Но тут уже зависит от процессов, у кого-то совсем нет документации, только маленькие чек-листы, сначала пишутся авто тесты, потом автотесты генерируют документацию, при этом документация всегда актуальна т.к. мы чиним тесты. Кто-то на оборот, сначала пишет тест кейсы, потом на основе них делает автотесты. Лично мне нравится первый подход
Я думаю, все поняли о чем речь, в python все же нет такой типизации, как например, в C# или Java. Даже если мы указываем явно тип переменной int, в python ничего не мешает нам потом сделать эту переменную строкой. Я как раз это имел ввиду, и поэтому сказал, что pydantic якобы реализует "строгую типизацию", т.к. он будет ругаться, на все, что не подходит под нужный тип, специально даже выделил кавычками, думал меня поймут, но нет. Короче кому надо, тот будет использовать и не так важно, как это называется
Мне кажется это каким-то бредом, приходить читать статью где тестируют rest api и минусовать ее за то, что нет ничего кроме http протокола
Это равно тому, если бы вы пришли в магазин "одежа" и сказали, а какого фига тут нет капусты?
Я описал лишь концепцию, далее есть множество путей развития
Мне кажется, более реальная причина хейта кроется в российском менталитете. Благодарный читатель будет извелекать 150% информации из работы любого автора, инфантил же, скажет, что одна вода и вообще автор дурак
Вот это кринж. Подумайте логически, если на бэке схема изменится, то со стороны авто тестов, она будет прежней, мы получим разницу и фейленный тест.
Под документацией имелось ввиду, типизация объектов по максимуму
Меня все устраивает, вы и комментатор выше, можете посмотреть, если вам так это нужно. Я лишь описал концепцию, думаю смышленые люди разберутся, что им нужно
Мне вот интересно, как такие умники дебажат авто тесты? Если в отчете только абстрактная информация, без какой-то конкретики
Еще немного кринжа. Строгая типизация и динамическая строгая типизация это разные вещи, советую изучить этот вопрос
Еще немножко кринжа, оставлю это без комментариев
Да, что-то можно было бы вынести в модели
Эта статья была написана для людей, которые хотят найти верный подход для написания автотестов. Все выше почему-то воспринимаю это, как туториал, что ошибочно. Если вас не устраивают какие-то моменты, то это ваши проблемы, задача статьи только в том, чтобы описать концепцию. Описать все подходы, использовать все супер модные либы, отполировать все до идеала, не входило в мои планы
Я написал только те требования к API, которые нужны лично мне или большинству для написания API авто тестов. И даже специально написал "Для меня требования выше являются базой, ваши же требования могут быть другие в зависимости от продукта. "
Да, в этом и проблема. Люди учатся по материалам, которые заведомо учат их неправильному. Далее компания становится пелйграундом для такого человека, пока он не попадет в команду, где его чему-то научат. У некоторых это не случается никогда
Да, наверное и в разработке и везде есть такое. Но, как показывает моя практика, с такими людьми можно успешно бороться и пускать их пыл все переписать в нужное русло
На github есть все зависимости и версии. Я не стал заморачиваться с poetry, моя главная задача это авто тесты. Статья и так получилась очень большая. Есть много репортеров allure, pytest-html, report-portal, junit, но тут даже речь не о репортере, сейчас почти все +- не бедные компании используют Allure TestOPS, в нем есть все, от коллаборации Manual + Automation инженеров, до аналитики и статистики, короче топовая штука.
В python нет строгой типизации. У python динамическая строгая типизация https://ru.wikipedia.org/wiki/Python, это означает, что одна и так же переменная может иметь разный тип в процессе выполнения программы. Где используется Pydantic тоже субъективно, где только не используется, некоторые даже умудряются пихать его в Django.
Без комментариев
Если положить настройки в фикстуру, то потом фикстура будет доступна только в скоупе тестов. То есть если вы захотите добавить какой-либо скрипт, который например чистит стенд или создает окружение или еще что-то, то фикстура тут будет не доступна. Это не гибкое решение. И даже если положить настройки в фикстуру, то потом придется эти настройки передавать в каждую функцию/класс и получится огромная вложенность. По поводу елипсов, их даже в документации используют https://docs.pydantic.dev/usage/settings/, но я знаю, что не обязательно
Наследовать тут не вариант т.к. типы у объектов будут разные. Как в pydantic сделать все поля опциональными я не нашел, по крайней мере официального решения, есть только костыли и хаки. Да, можно через функцию сделать, например get_random, но я не вижу проблем с default_factory.
Не совсем понял, в чем тут проблема
Не люблю использовать root_validator, но можно валидировать и в нем. В тестах используется expect, дефолтный assert хоть и хорош с pytest-ом, но он не даст нам allure.step
Не говорил, что это единственное правильное решение и никак иначе нельзя... Данный подход лишь закрывает те бизнес потребности, которые возникаю лично у меня. Для меня этот подход единственный правильный
Если есть какое-то другое решение, то вы можете написать свою статью и написать свое "правильное" решение :)
Да, тесты пишем именно таким образом. Отличие в том, что сама структура тестов более сложная, в статье много было опущено, + мы используем async await для всех тестов API и UI.
Тестов достаточно много, 3000+ API тестов. Поддерживать с таким подходом просто, гораздо сложнее поддерживать было ранее.
Я пришел к данному подходу спустя несколько лет разных проектов, разных компаний, разных команд (от 1 QA Automation на 1 проект, до 5-7 QA Automation в одной команде). Куда бы не попадал, везде были похожие проблемы, похожие решения. Потом я изучал очень много данных по автоматизации тестирования, это были, как русскоязычные, так и англоязычные ресурсы. После нескольких лет практики, я вывел одну важную вещь: даже если компания крупная, даже если там большая команда QA Automation и большой продукт, это не мешает QA Automation инженерам изобретать велосипеды. Ну или в компании может быть главный "велосепедист") Такого человека еще в шутку называют "Хранитель говнокода") Обычно это QA Automation, который пришел в команду раньше всех и почти весь фреймворк написал он, ни в коем случае не хочу никого оскорбить, просто так бывает
1. Сначала мне хотелось решить проблему с типизацией в автотестах. Изначально все выглядело так
def create_something_api(payload: dict, user: dict = None) -> Response:
...
Где-то писалось так:
class CreateSomethingPayload(dict):
"""Тут мб какое-то описание"""
pass
def create_something_api(payload: CreateSomethingPayload) -> Response:
...
Но мне ни первая, ни вторая записи не нравились. + В команде менялись люди, кто-то уходил на другой проект, потом брали новых QA Automation, иногда это были даже джуны. Часто случалось так, что тот человек, который писал этот код уходил из компании и уже было сложно понять, что же там написано. Усложнялось тем, что не на всех проектах был сваггер и документации по API не было, как правило это компании стартапы, которых сейчас не мало. Даже если сваггер был, то ходить каждый раз в сваггер было не удобно + шанс запутаться был только выше.
Потом на помощь пришли dataclass-ы. Которые +- решили проблему с типизацией. Но сразу же появились проблемы с тем, чтобы конвертировать модель dataclass-а в json/dict, генерировть схему. Тут на помощь пришла либа dataclasses-json, которая делает +- тоже самое что и pydantic, где-то криво-косо, но на тот момент было хорошо. Но в текущих реалиях, я 100% отдаю голос за pydantic, у него намного больше фичей, чем у dataclasses-json.
2. Еще была проблема с json schema. Ее хардкодили, автоматически схему никто не генерировал. Мне тоже это не нравилось т.к. в проекте было ну очень много enum-мов, со всякими статусами, кодами, было много сущностей, у которых было поле type, которое было enum-мом. Обычные сайты по типу generate json schema online могут сгенерировать схему для простого объекта, но они не учитывают что какое-то поле не просто striing, а 'enum': ['started', 'finished'].
Из-за хардкода схемы приходилось делать в два раза больше работы. Если разработчики обновили type какой-то сущности, то нам нужно было обновить enum в автотестах + переписать схему руками, ведь online генератор в этом не поможет. + Иногда люди криво писали схему и совсем забывали, что поле не просто integer, а какой-то конкретный enum.
Эта проблема решилась вместе с dataclass-ми + либа dataclasses-json. Всю хардкоженную схему убрали. Теперь при изменении enum-ма схема автоматически обновлялась, т.к. генерировалась автоматически.
Наверное тут можно было бы сказать, что эту проблему можно было бы решить автоматически через генерацию клиента на основе swagger. Да, согласен, если у вас есть ресурсы и время, на написание скриптов для генерации клиента. Но на практике именно для python я не видел таких скриптов, только для Java.
3. Лично мой выбор, это отказ от requests в пользу httpx. Потому что сейчас все пишем через async await, ну и философия библиотеки httpx мне больше близка. Но requests тоже очень даже хорошая либа
В принципе SearchModal можно наследовать от BasePage, при необходимости. Но как по мне Components не должны наследоваться ни от кого (если только нет родительских компонентов).
Например если мы говорим про модальное окно логина, которое предлагает нам войти в систему, то это Component. Поля ввода, кнопки, иконки в этом модальном окне будут считаться, как Page Factory. Модальное окно логина, может быть использовано на разных страницах, поэтому мы выносим это в отдельный слой - Component. В автотестах мы сможем использовать этот Component на разных страницах, например DasboardPage, FormsPage, ProfilePage и т.д. нам будет достаточно использовать композицию и не дублировать код. Page Factory же поможет нам, удобнее работать с элементами внутри модального окна логина.
Надеюсь, я правильно понял ваш вопрос)
Рад, что статья оказалась полезной. Давайте по вопросам:
Да, такой вариант тоже возможен Модель.parse_obj(ответ), вполне. Для моделей у которых несколько разных типов полей можно использовать объединения. Например у нас есть JSON объект, в котором есть поля
{"id": 1, "state": 1}. Поле "state" может быть строкой, числом, списком из чисел. Тогда модель будет выглядеть такДля python 3.10+ эта запись может быть другой, например
state: str | int | list[int]. В итоге при генерации схемы мы получим поле state в таком форматеВ данном случае поле state является anyOf string, integer, array + items integer. То есть все эти JSON объекты будут валидны
Таким образом, мы можем описывать разные типы полей. Надеюсь я правильно понял ваш вопрос
Ну тут нужно смотреть индивидуально ваш продукт. Не смогу сказать точно, как это сделать именно для вашего проекта, т.к. мне нужно будет знать много пунктов. Вот, что можно предпринять:
1. Выбрать правильную структуру для моделей. Например у нас есть сервисы users, grading, payments
Тогда раскладываем модели так:
models/users/user.py
models/users/auth.py
models/users/emails.py
models/grading/score.py
models/grading/grade_scale.py
models/payments/orders.py
models/payments/items.py
Это должно решить проблему с запутанностью. Понятно, что у вас скорее всего структура будет намного сложнее, но суть к остается та же. Если раскидать модели по правильной структуре, то мы сможем всегда знать, где находится нужная нам модель.
2. Если же у вас ситуация по типу, когда внутри одного и того же объекта могут быть разные модели, например
То в таком случае, чтобы не писать каждый раз новую модель и не дублировать код, можно воспользоваться Generic моделью
В таком случае T будет динамически заменяться на тот тип, который вы передадите. Это поможет избежать дублирования кода, если внутри какой-то общей/глобальной модели используются разные модели из других сервисов.
Возможно дополнительный слой нужен. В примере с questions я писал два метода
create_question_api
create_question
Внутри create_question хорошо было бы добавить проверку, черед тем, как прокидывать response.json() внутрь модели, то есть:
Тогда в случае ошибки мы упадем раньше, чем попадем в модель.
Можно поступить по другому, в pydantic есть такая киллер штука, как ValidationError, с помощью нее, мы можем сформировать очень даже читабельное и понятное сообщение об ошибке в отчете. Например нам из API пришел пустой объект, тогда мы можем попробовать спарсить его и если что-то не так, то кинуть сообщение об ошибке
Фишка тут в error.json(), эта ошибка будет выглядеть примерно так
Что +- можно прочитать и понять, что именно было не так. Дальше уже вопрос в том, как вы это будете применять. Можете написать обертку, которая сначала будет пытаться запихнуть json в модель, если не получится то выбросит ошибку в json формате. JSON формат ошибки можно настроить или отформатировать, как вам удобно
Да, можно промисы через then, catch, это ведь тоже самое, что и async/await. Тут вопрос только в том, как мы это используем. Кто понял, тот понял)
Когда фронтенд разработчики пишут приложение, у них есть понятия screen/page, module/component. То есть страница (Page) состоит из компонентов (Component), компонентами могут быть, модальные окна, формы, карточки, лист айтемы, и т.д. Page Factory это больше про то, как мы работаем с локаторами. В Page Factory мы оцениваем локатор, как какой-то конкретный объект или свойство. Ну если привести пример из жизни, то все элементы это конструктор lego, Page - это собранная модель, Component - это отдельные части, рука, нога, голова, Page Factory - это сами детальки lego)
Преимущества описывал выше, в разделе "Page Factory", посмотрите, там достаточно много пунктов и подробно описано. Возможно это не классическое представление Page Factory, но единственное рабочее для моих целей, цели я тоже описал
Да, прикольная фича, возьму на заметку. Я привык писать на python, там такой возможности нет
typeOf переопределяется для отчета, в отчете будет видно с каким объектом мы работали. То есть Click on button(typeOf) with name "Hello", Click on input(typeOf) with name "Some"
typeOfUpper - возможно да, но вам стоит помнить, что эта статья не туториал. Я не пытаюсь рассказать людям как писать супер правильный TS код, мне больше интересно показать, как лучше писать UI авто тесты.
Не совсем, тут много причин:
Чтобы динамически обработать и сгенерировать нужный нам локатор и только потом использовать объект локатора в методе
Чтобы уникализировать методы работы с объектами на странице. Я приводил пример выше с .toBeVisible(), .isVisible(), оба метода выполнят задачу, но правильный по сути только один. Да, на hover это не распространяется, тут этот пункт работать не будет
Если вы тестируете продукт, в котором есть специфические компоненты, например для hover на такой компонент, необходимо сначала кликнуть куда-то, ну или в этом духе. Тогда можно делать кастомные компоненты, например MyCustomButton, внутри реализовывать именно тот hover, который будет кликать, а потом делать hover. Ну это чисто пример, на практике разное бывает
Да, нужен читабельный шаг для отчета. По дефолту playwright делает шаги, но они не отражают бизнес логику, которую мы тестируем. + Как показывает практика, manual qa и менеджерам очень сложно читать дефолтные шаги от Playwright, они не информативны
Приятно слышать, что кому-то материал оказался полезен)
По поводу комментариев, абсолютно с вами согласен. Критиковать кого-то намного проще, чем похвалить, для критики или хейта даже слова легче подобрать, нежели для положительного фидбэка
Рад слышать, что статья оказалась полезна вам!)
Мне кажется мы с вами про разное говорим
Я бы сказал так, что документации в виде типов будет достаточно для понимания. Но еще бы хотелось, чтобы на основе авто тестов генерировалась тестовая документация, то есть тест кейсы. Но тут уже зависит от процессов, у кого-то совсем нет документации, только маленькие чек-листы, сначала пишутся авто тесты, потом автотесты генерируют документацию, при этом документация всегда актуальна т.к. мы чиним тесты. Кто-то на оборот, сначала пишет тест кейсы, потом на основе них делает автотесты. Лично мне нравится первый подход
Я думаю, все поняли о чем речь, в python все же нет такой типизации, как например, в C# или Java. Даже если мы указываем явно тип переменной int, в python ничего не мешает нам потом сделать эту переменную строкой. Я как раз это имел ввиду, и поэтому сказал, что pydantic якобы реализует "строгую типизацию", т.к. он будет ругаться, на все, что не подходит под нужный тип, специально даже выделил кавычками, думал меня поймут, но нет. Короче кому надо, тот будет использовать и не так важно, как это называется
Мне кажется это каким-то бредом, приходить читать статью где тестируют rest api и минусовать ее за то, что нет ничего кроме http протокола
Это равно тому, если бы вы пришли в магазин "одежа" и сказали, а какого фига тут нет капусты?
Я описал лишь концепцию, далее есть множество путей развития
Мне кажется, более реальная причина хейта кроется в российском менталитете. Благодарный читатель будет извелекать 150% информации из работы любого автора, инфантил же, скажет, что одна вода и вообще автор дурак
Вот это кринж. Подумайте логически, если на бэке схема изменится, то со стороны авто тестов, она будет прежней, мы получим разницу и фейленный тест.
Под документацией имелось ввиду, типизация объектов по максимуму
Меня все устраивает, вы и комментатор выше, можете посмотреть, если вам так это нужно. Я лишь описал концепцию, думаю смышленые люди разберутся, что им нужно
Мне вот интересно, как такие умники дебажат авто тесты? Если в отчете только абстрактная информация, без какой-то конкретики
Еще немного кринжа. Строгая типизация и динамическая строгая типизация это разные вещи, советую изучить этот вопрос
Еще немножко кринжа, оставлю это без комментариев
Да, что-то можно было бы вынести в модели
Эта статья была написана для людей, которые хотят найти верный подход для написания автотестов. Все выше почему-то воспринимаю это, как туториал, что ошибочно. Если вас не устраивают какие-то моменты, то это ваши проблемы, задача статьи только в том, чтобы описать концепцию. Описать все подходы, использовать все супер модные либы, отполировать все до идеала, не входило в мои планы
Без кометариев
Я написал только те требования к API, которые нужны лично мне или большинству для написания API авто тестов. И даже специально написал "Для меня требования выше являются базой, ваши же требования могут быть другие в зависимости от продукта. "
Да, в этом и проблема. Люди учатся по материалам, которые заведомо учат их неправильному. Далее компания становится пелйграундом для такого человека, пока он не попадет в команду, где его чему-то научат. У некоторых это не случается никогда
Да, наверное и в разработке и везде есть такое. Но, как показывает моя практика, с такими людьми можно успешно бороться и пускать их пыл все переписать в нужное русло
На github есть все зависимости и версии. Я не стал заморачиваться с poetry, моя главная задача это авто тесты. Статья и так получилась очень большая. Есть много репортеров allure, pytest-html, report-portal, junit, но тут даже речь не о репортере, сейчас почти все +- не бедные компании используют Allure TestOPS, в нем есть все, от коллаборации Manual + Automation инженеров, до аналитики и статистики, короче топовая штука.
В python нет строгой типизации. У python динамическая строгая типизация https://ru.wikipedia.org/wiki/Python, это означает, что одна и так же переменная может иметь разный тип в процессе выполнения программы. Где используется Pydantic тоже субъективно, где только не используется, некоторые даже умудряются пихать его в Django.
Без комментариев
Если положить настройки в фикстуру, то потом фикстура будет доступна только в скоупе тестов. То есть если вы захотите добавить какой-либо скрипт, который например чистит стенд или создает окружение или еще что-то, то фикстура тут будет не доступна. Это не гибкое решение. И даже если положить настройки в фикстуру, то потом придется эти настройки передавать в каждую функцию/класс и получится огромная вложенность. По поводу елипсов, их даже в документации используют https://docs.pydantic.dev/usage/settings/, но я знаю, что не обязательно
Наследовать тут не вариант т.к. типы у объектов будут разные. Как в pydantic сделать все поля опциональными я не нашел, по крайней мере официального решения, есть только костыли и хаки. Да, можно через функцию сделать, например get_random, но я не вижу проблем с default_factory.
Не совсем понял, в чем тут проблема
Не люблю использовать root_validator, но можно валидировать и в нем. В тестах используется expect, дефолтный assert хоть и хорош с pytest-ом, но он не даст нам allure.step
Приятно слышать, что пригодилось :)
Не говорил, что это единственное правильное решение и никак иначе нельзя... Данный подход лишь закрывает те бизнес потребности, которые возникаю лично у меня. Для меня этот подход единственный правильный
Если есть какое-то другое решение, то вы можете написать свою статью и написать свое "правильное" решение :)
Спасибо, забыл добавить abstractmethod к type_of