Имеется проект по автоматизации на web + serverside автоматизации на pytest с параллельным запуском тестов. Есть задача перейти на #bdd. Казалось бы все хорошо. Есть pytest-bdd для #pytest который имеет на 90% все что нам нужно и легко вписывается в текущий проект, но он не развивается последнее время и имеет некоторые нереализованные фичи #gherkin. С другой стороны есть #behave который активно развивается, имеет самое большое покрытие #gherkin синтаксиcа и имеет поддержку IDE, а также широко используется и поддерживается #python коммьюнити. Но переезд на behave займет время и усилия. Ну и есть #robot-framework. Внимание вопрос:
Мы у нас на проекте начинали с Behave но потом перешли на py.test . Проблема была в том что Behave немного криво заиспользовали с самого начала и потом было очень сложно все поддерживать.
Почему тогда начинали не с py.test ? - было требование от менеджмента а потом мы поняли что никто #gherkin не использует кроме тестировщиков.
Имхо - использовать только то, что развивается. То что не развивается - всегда нуждается в костылях.
Второе имхо - сам принцип БДД, это как пригласить домой электрика чинить телевизор, но не давать ему работать самостоятельно, а постоянно говорить что-то вроде: вот возьми эту неонятную фигню, ударь по ней молотком, а потом припаяй сюда, и я хочу чтобы после этого на 3 показывал НТВ.
Все так, все правда, но есть обратная сторона менеджмента деньги. Менеджмент не всегда понимает почему ему надо потратить деньги чтобы переписать все, тем более что есть более дешевая опция, как в данном случае.
Сейчас используем просто py.test - всем пофиг на чем и как мы пишем Пога нету критикал багов )))
Мы не кинулись переводить все сразу. Новые сервисы и тесты писали по новому а потом уже начали подтягивать старые.
Ну тогда можно сказать менеджменту что в связи с тем что python-bdd заброшен, найти тех кто знает этот пакет через 3-4 года будет очень тяжело и в случае ухода своих специалистов им придется либо уходящих перекупать зарплатой, либо искать тех спецов с выслугой лет которые застали этот пакет и которые благодаря выслуге лет стоят очень дорого.
Грубо, неправда конечно же, пакет выучить не составит труда, но для менеджмента который просто не понимает пойдет.
Остался бы на чистом пайтесте, ибо никакие там gherkin-конструкции не заменят качественно написанные фикстуры, имхо. Плюс эта лишняя прослойка с парсингом степов…Не понимаю. Cам писал для одного проекта BDD фреймворк с Behave и не увидел профита от этого подхода кроме зеленых шагов в аутпуте. Нет, понятно что за денежку можно написать и на паскале. Но все же, если на проекте не отмахнуться от BDD, то я бы переписал все на Behave
ИМХО, #bdd это никому не нужный уровень абстракции. Если задача перейти на #bdd пришла от менеджмента, то это закончится тем, что менеджмент или тот, для кого это делается, поиграются немного и забудут.
Тут главный вопрос “зачем?” (“кому это нужно?”). Сильно сомневаюсь, что автоматизаторы сами захотели это. Отказывайтесь от #bdd фреймворков в автоматизации тестирования всеми возможными путями ибо это путь в никуда.
Активно пользовался behave последний год или больше. В целом ниче инструмент, но есть много глюков и мелких багов (хотя если не использовать кириллицу и другие специфичные языки, то возможно проблем будет меньше). В pytest-bdd на сколько я помню небыло возможности шарить между степами контекст, хотя я могу ошибаться. Я бы выбрал все же робота как более стабильный инструмент.
Паттерны и анти-паттерны использования BDD. Опыт реальных проектов[quote=“NikS, post:11, topic:16851”]
Тут главный вопрос “зачем?” (“кому это нужно?”). Сильно сомневаюсь, что автоматизаторы сами захотели это. Отказывайтесь от #bdd фреймворков в автоматизации тестирования всеми возможными путями ибо это путь в никуда.
[/quote]
Автоматизаторы часто этого и не хотят, их заставляют. Другой вопрос насколько менеджмент делает все для того чтобы #bdd заработал? Обычно кроме решения они ничего не делают, а немотивированная команда и не вовлечение аналитиков и бизнес-юзеров сводят эффект от bdd к нулю.
Да это так и есть, хотя это можно с легкостью обойти через воркараунд.[quote=“rmerkushin, post:12, topic:16851”]
Я бы выбрал все же робота как более стабильный инструмент.
[/quote]
Спасибо, робот может быть впишется если на него согласятся.
На прошлой работе вовсю использовали Cucumber. очень удобно. Сразу понятно, что тест делает, не вчитываясь в реализацию. Особенно, когда люди перекидываются из проекта в проект.
testomat.io управление авто тестами
