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

bdd
pytest
gherkin
behave
Теги: #<Tag:0x00007fedbc6a5ca0> #<Tag:0x00007fedbc6a5b10> #<Tag:0x00007fedbc6a59d0> #<Tag:0x00007fedbc6a5818>

(Mykhailo Poliarush) #8

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


(Mykhailo Poliarush) #9

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


(Maxim Andryushchenkov) #10

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


(Nik Sidorenko) #11

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

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


(rmerkushin) #12

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


(Mykhailo Poliarush) #13

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

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

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


(Mykhailo Poliarush) #14

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

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


(Максим Таран) #15

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


(rmerkushin) #16

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


(Максим Таран) #17

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


(rmerkushin) #18

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


(rmerkushin) #19

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


(Mykhailo Poliarush) #20

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


(rmerkushin) #21

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


(Mykhailo Poliarush) #22

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


(rmerkushin) #23

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


(Den Silver) #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й путь.


(Den Silver) #25

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

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


(Mykhailo Poliarush) #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


(Mykhailo Poliarush) #27

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