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

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

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

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

0 участников

3 Likes

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

1 Like

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

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

5 Likes

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

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

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

1 Like

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

2 Likes

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

1 Like

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

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

2 Likes

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

1 Like

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

1 Like

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

1 Like

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

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

2 Likes

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

2 Likes

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

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

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

1 Like

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

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

1 Like

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

1 Like

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

1 Like

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

1 Like

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

1 Like

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

1 Like

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

1 Like