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

bdd
pytest
gherkin
behave
Теги: #<Tag:0x00007fedb6cfe328> #<Tag:0x00007fedb6cfe170> #<Tag:0x00007fedb6cfdfe0> #<Tag:0x00007fedb6cfde50>

(Mykhailo Poliarush) #1

Имеется проект по автоматизации на web + serverside автоматизации на pytest с параллельным запуском тестов. Есть задача перейти на #bdd. Казалось бы все хорошо. Есть pytest-bdd для #pytest который имеет на 90% все что нам нужно и легко вписывается в текущий проект, но он не развивается последнее время и имеет некоторые нереализованные фичи #gherkin. С другой стороны есть #behave который активно развивается, имеет самое большое покрытие #gherkin синтаксиcа и имеет поддержку IDE, а также широко используется и поддерживается #python коммьюнити. Но переезд на behave займет время и усилия. Ну и есть #robot-framework. Внимание вопрос:

Чтобы вы сделали в данной ситуации?

  • Использовал бы pytest-bdd
  • Переписал бы все на behave
  • Переписал бы на robotframework
  • Другое, напишу в комментариях

0 участников


#2

Мы у нас на проекте начинали с Behave но потом перешли на py.test . Проблема была в том что Behave немного криво заиспользовали с самого начала и потом было очень сложно все поддерживать.
Почему тогда начинали не с py.test ? - было требование от менеджмента а потом мы поняли что никто #gherkin не использует кроме тестировщиков.


(Artur Korobeynyk) #3

Имхо - использовать только то, что развивается. То что не развивается - всегда нуждается в костылях.

Второе имхо - сам принцип БДД, это как пригласить домой электрика чинить телевизор, но не давать ему работать самостоятельно, а постоянно говорить что-то вроде: вот возьми эту неонятную фигню, ударь по ней молотком, а потом припаяй сюда, и я хочу чтобы после этого на 3 показывал НТВ.


(Mykhailo Poliarush) #4

По каким соображениям?
Я так понимаю сейчас используете #pytest #bdd. Какие проблемы \ костыли заметили при реализации тестов?

А как его можно использовать неправильно?

Как всегда … :slight_smile:


(Mykhailo Poliarush) #5

Все так, все правда, но есть обратная сторона менеджмента деньги. Менеджмент не всегда понимает почему ему надо потратить деньги чтобы переписать все, тем более что есть более дешевая опция, как в данном случае.


#6

Сейчас используем просто py.test - всем пофиг на чем и как мы пишем :slight_smile: Пога нету критикал багов )))
Мы не кинулись переводить все сразу. Новые сервисы и тесты писали по новому :slight_smile: а потом уже начали подтягивать старые.


(Artur Korobeynyk) #7

Ну тогда можно сказать менеджменту что в связи с тем что python-bdd заброшен, найти тех кто знает этот пакет через 3-4 года будет очень тяжело и в случае ухода своих специалистов им придется либо уходящих перекупать зарплатой, либо искать тех спецов с выслугой лет которые застали этот пакет и которые благодаря выслуге лет стоят очень дорого.

Грубо, неправда конечно же, пакет выучить не составит труда, но для менеджмента который просто не понимает пойдет.


(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