py.test-bdd или behave. Что бы вы использовали? Плюсы и минусы

программирование python
, , ,
#8

Ну так у вас обратный переход с #bdd на просто DSL в коде.

1 лайк
#9

Да на этот пункт они могут повестись. Спасибо за подсказку. :thumbsup:

1 лайк
#10

Остался бы на чистом пайтесте, ибо никакие там gherkin-конструкции не заменят качественно написанные фикстуры, имхо. Плюс эта лишняя прослойка с парсингом степов…Не понимаю. Cам писал для одного проекта BDD фреймворк с Behave и не увидел профита от этого подхода кроме зеленых шагов в аутпуте. Нет, понятно что за денежку можно написать и на паскале. Но все же, если на проекте не отмахнуться от BDD, то я бы переписал все на Behave

1 лайк
#11

ИМХО, #bdd это никому не нужный уровень абстракции. Если задача перейти на #bdd пришла от менеджмента, то это закончится тем, что менеджмент или тот, для кого это делается, поиграются немного и забудут.

Тут главный вопрос “зачем?” (“кому это нужно?”). Сильно сомневаюсь, что автоматизаторы сами захотели это. Отказывайтесь от #bdd фреймворков в автоматизации тестирования всеми возможными путями ибо это путь в никуда.

2 лайка
#12

Активно пользовался behave последний год или больше. В целом ниче инструмент, но есть много глюков и мелких багов (хотя если не использовать кириллицу и другие специфичные языки, то возможно проблем будет меньше). В pytest-bdd на сколько я помню небыло возможности шарить между степами контекст, хотя я могу ошибаться. Я бы выбрал все же робота как более стабильный инструмент.

2 лайка
#13

Да это тоже видно по этому опросу

Паттерны и анти-паттерны использования BDD. Опыт реальных проектов[quote=“NikS, post:11, topic:16851”]
Тут главный вопрос “зачем?” (“кому это нужно?”). Сильно сомневаюсь, что автоматизаторы сами захотели это. Отказывайтесь от #bdd фреймворков в автоматизации тестирования всеми возможными путями ибо это путь в никуда.
[/quote]

Автоматизаторы часто этого и не хотят, их заставляют. Другой вопрос насколько менеджмент делает все для того чтобы #bdd заработал? Обычно кроме решения они ничего не делают, а немотивированная команда и не вовлечение аналитиков и бизнес-юзеров сводят эффект от bdd к нулю.

1 лайк
#14

Да это так и есть, хотя это можно с легкостью обойти через воркараунд.[quote=“rmerkushin, post:12, topic:16851”]
Я бы выбрал все же робота как более стабильный инструмент.
[/quote]

Спасибо, робот может быть впишется если на него согласятся.

1 лайк
#15

На прошлой работе вовсю использовали Cucumber. очень удобно. Сразу понятно, что тест делает, не вчитываясь в реализацию. Особенно, когда люди перекидываются из проекта в проект.

1 лайк
#16

Ну огурец тут не вписывается никак из-за Java\JS\Ruby, ибо нужен Python как я понимаю)

1 лайк
#17

Ну есть имплементация через Jython :slight_smile: (понимаю, что извращение)

1 лайк
#18

По моему это так же дурно пахнет как и Java + Robot Framework )

1 лайк
#19

А ты не смотрел на https://getgauge.io ? Там вроде Python можно и тоже bdd

1 лайк
#20

Нет, там нет реализации под #python

1 лайк
#21

Хмм ну вот есть плуг для него. http://gauge-python.readthedocs.io/en/latest/

#22

Ок, да согласен есть неофициальная поддержка, но для больших компаний важно именно официальная поддержка.

#23

Ок, бывает, У нас тоже докер не продакшн реди оказался )

#24

У Behave есть один большой недостаток. Он не позволяет распаралелить тесты! Вернее даже не так. Его дефолтными возможностями он этого не позволяет. Можно привлечь behave-parallel, но это такой КОСТЫЛЬ, что поработав с ним, плюнули, и пришли pytest-bdd. Behave вроде как обещают внедрить таки паралелизацию в релизе 1.3. Что это нам даёт? Написав тесты на pytest-bdd будет уже проделан большой скоуп работ. После того как behave таки внедрят паралелизацию тестов, затраты на переход к Behave будут минимальны, поскольку болшая часть уже будет написана. Надо будет только подправить сами тесты.
Тажке ещё один нюанс. Behave не правильно генерирует json который был бы совместим с Cucumber. То есть, если на дженкинсе установить плагин Cucumber report то, он просто не будет его понимать. Но это лечится через перегон файла посредствами behave2cucumber либы. И того мы имеем 2 путЯ:

  1. Писать сразу на Behave и надеятся что они таки реализуют распаралеливание тестов +нормальную генерацию json репорта соместимого с Cucumber report
  2. Писать на pytest-bdd, запорачиваясь в IDEшках связок степ дефенишенов, и после того как Behave реализуют распаралеливание перейти на него с меньшыми затратами.

Мы выбрали 2й путь.

1 лайк
#25

В pytest-bdd на сколько я помню небыло возможности шарить между степами контекст

Это реализуется через request. BasePage.request.user_email = значение

#26

Из коробки до сих пор такого нет, но это легко реализуется с помощью fixture

@pytest.fixture(scope='session')
def context():
    """Context object to store data to be passed between steps"""
    return Context()

@given('test step 1')
def test1(context):
    context.id = 1233

@given('test step 2')
def test1(context):
    print context.id
#27

В общем, мы тоже выбрали второй вариант, имеет только один большой плюс #behave это поддержка в #pycharm