Было бы еще здорово указывать импорты в примерах кода и пути к модулям в комментарии в первой строке.
Почему вы считаете, что наличие фикстур прямо во фреймворке - это не смешение ответственности? Фреймворк ведь описывает взаимодействие и предоставляет инструменты, а pytest с его фикстурами создает объекты и подготавливает условия, пред и пост.
И в примере тестов у вас в теле теста и предусловия, и постусловия и шаги и проверки. Почему вы решили не выносить предусловия (например, создание сущности через апи для логина через ui) в фикстуру, а в тесте использовать уже ее объект. Получилось бы лаконичнее и чище.
На самом деле обход каталога занимает абсолютно незначительное время, меньше секунды для сотен файлов. Фаза collecting в Pytest выполняется до запуска тестов, тест получает уже готовые параметры, сохраненные в памяти и готовые к использованию. Это хороший вопрос об экономии, но в сценарии из статьи тратится слишком мало ресурсов.
Состав файлов-параметров в теории может меняться после коллекта параметров, но вопрос в целесообразности этих операций. Лучшая защита - точно понимать что, когда и зачем делает ваш код, какая логика реализуется.
В примере из статьи мы уже в example_parametrizer вычитываем данные из .yaml, тест получает фиксированные и синхронизированные данные.
Рад, что оказалось полезным. На самом деле это очень универсальная штуковина для параметризации тестирования создания и обновления сущностей. В .yaml-файл можно положить разные строки для разных полей, их комбинации, ожидаемые данные.
Получится, что тест создает сущность с вашими параметрами из .yaml-файла. По мере обновления апи можно бдет добавлять новые сценарии. Как пример.
Шикарная статья, точное попадание в моем случае.
Было бы еще здорово указывать импорты в примерах кода и пути к модулям в комментарии в первой строке.
Почему вы считаете, что наличие фикстур прямо во фреймворке - это не смешение ответственности? Фреймворк ведь описывает взаимодействие и предоставляет инструменты, а pytest с его фикстурами создает объекты и подготавливает условия, пред и пост.
И в примере тестов у вас в теле теста и предусловия, и постусловия и шаги и проверки. Почему вы решили не выносить предусловия (например, создание сущности через апи для логина через ui) в фикстуру, а в тесте использовать уже ее объект. Получилось бы лаконичнее и чище.
Спасибо, классная статья, легко написана и приятно читается. Наконец-то упрочнил понимание super()
Интересные вопросы.
На самом деле обход каталога занимает абсолютно незначительное время, меньше секунды для сотен файлов. Фаза collecting в Pytest выполняется до запуска тестов, тест получает уже готовые параметры, сохраненные в памяти и готовые к использованию. Это хороший вопрос об экономии, но в сценарии из статьи тратится слишком мало ресурсов.
Состав файлов-параметров в теории может меняться после коллекта параметров, но вопрос в целесообразности этих операций. Лучшая защита - точно понимать что, когда и зачем делает ваш код, какая логика реализуется.
В примере из статьи мы уже в
example_parametrizerвычитываем данные из .yaml, тест получает фиксированные и синхронизированные данные.Рад, что оказалось полезным. На самом деле это очень универсальная штуковина для параметризации тестирования создания и обновления сущностей. В .yaml-файл можно положить разные строки для разных полей, их комбинации, ожидаемые данные.
Получится, что тест создает сущность с вашими параметрами из .yaml-файла. По мере обновления апи можно бдет добавлять новые сценарии. Как пример.