куа ниндзя прям

> assert matcher.has_length_less_than(self.checklists_by_tags.get_all_tags_elements(), 1)

assert len(blabla.get_all_tags_elements()) == 1

Ток < 1, наверное. less_than же

da

Ребята, есть вопрос
Кто то работал с https://github.com/microsoft/azure-devops-python-api ?
И если да, то возможно есть у кого то опыт в добавлении скриншота в test results attacments?
Если что то другое использовали, буду благодарна если поделитесь инфой. Задача в том что бы добавить скрин в test results attacments в azure devops
Заранее спасибо

Экспериментировал в свободное время. Завёл круговую джобу и на пуш в репу, но с аттачами пока не работал.
У вас на проекте Azure?

Да)

Привет. Вопрос на ночь глядя про переиспользование функций при использовании allure.

Если я использую pytest-bdd, то в общем и целом это выглядит так:

В steps пишу функции, обернутые декораторами типа @given,@when и т.д. Например:

    @when('Описание шага сценария на человечьем языке')
    def step_<function_name>(context):
        ....код, который что-то делает....

Далее я создаю feature-файл, в котором на gerkin пишу сценарий, используя описания шагов сценария, которые ранее прописал в декораторах.
Таким образом, один раз написав функцию и обернув ее декоратором, я могу много раз легко ее переиспользовать в различных сценариях, создавая различные feature-файлы

Если я использую pytest + allure, то это выглядит так:
Пишу функцию, обернутую декоратором @allure. Например:

      @allure.step('Описание шага сценария на человечьем языке')
    def test_<function_name>(self):
          ....код, который что-то делает....

И все! Дальше запускается pytest, отрабатывает сценарий, генерирует отчет, который скармливается allure, в котором мы видим описание шагов, указанные в декораторе.
Но в этом случае, если я захочу создать еще один сценарий, где используется тот же функционал, реализованный в ранее написанной функции, то мне фактически придется проделать всю работу заново: нужно написать опять функцию и опять обернуть ее декоратором.
В отличие от pytest-bdd, в котором переиспользование возможно, и выше я написал как.

Вопрос: есть ли инструменты переиспользования функций в связке pytest+allure подобно тому, как это реализовано в pytest-bdd? Какие решения вобще могут быть?

1. Не уловил зачем на тест (def test_...) навешивать декоратор степа, степы отдельными функциями, которые вызываются из теста
2. Что мешает вызвать функцию, с декоратором степа, несколько раз из разных тестов?

Я подобное решил так:
Вынес общий «шаговод» в класс и в хеплеры. Далее, на этапе инициализации в conftest.py передаю через фикстуры эти классы и использую.

- все в одном месте
- постоянно переиспользуется

в фикстуры вынес, т.к. в пред/пост условии юзается?
если же в степах только, то зачем через фикстуру делать?

Просто мне легче было построить так систему в своё время: что там нужно тестам? Окружение? В фикстуру. А что еще? Общие шаги? В фикстуру

Вот и получились два класса:
1) Steper - все шаги, обернутые в аллюр декоратор(все методы - статик)
2. Checker - все проверки, которые есть в системе(тоже статик методы)

поидее тогда в тесте ты перечисляешь все шаги в def test_....(шаг1, шаг 2 ....) ?

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

Пишется тест(если есть кастомная фикстура - использует)

В методе обычно так:

1. Выполнить какой-то шаг(обычно - отправка данных)
2. Вызывать проверки

ниче не понял)
ладно, если тебе удобно то ок)
суть в том что и без оборачивания все работает как обычный вызов функций-степов из функций-тестов

Мне очень хотеось избавиться от with allure.step()

Пишется просто:
Steper.send()

    @when('Описание шага сценария на человечьем языке')
    def step_<function_name>(context):
        ....код, который что-то делает....

      @allure.step('Описание шага сценария на человечьем языке')
    def test_<function_name>(self):
          ....код, который что-то делает....

Да, фикстуры. В них с помощью with step(): делаешь всякое. Потом в тестах, используешь эти фикстуры, степы видно в отчетах

Если можно статик, то класс не нужен🙃

1. Не понял, а на 2 вопрос: писать сценарий с функцией для вызова другой функции с декоратором - имхо криво, т.к. получится, что в этом сценарии декораторы использоваться не будут, а это большой минус - т.к. декораторы - очень удобный инструмент для чтения и понимания кода сценария. Фактически я удобное читабельное описание спрячу в глубины, а на поверхность выведу обычные функции с типовыми именами.

Всем спасибо. Совет про фикстуры понял. Попробую.