Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

BDD с использованием JBehave

jbehave
bdd
Теги: #<Tag:0x00007f7b705c5f88> #<Tag:0x00007f7b705c5e48>

(Шевченко Владислав) #1

Автоматизирую классически : WebDriver + Java + TestNG
Адепт PageObject’а.
Мне тут предлагают писать BDD тесты с использованием JBehave
Вопрос: Стоит ли? Какие подводные камни? Возможно ли это? В общем если у кого был похожий опыт - дайте знать.


(Дмитрий Жарий) #2

Самый важный вопрос – это зачем вам это нужно?

  • Какие проблемы вы хотите решить, переходом на другой инструмент и подход?
  • Что вас не устраивает в прежнем подходе?
  • Чего вы хотите достичь?

Немного философии



(Mykhailo Poliarush) #3

А что означают предлагают? Вам нечего делать? Или просто так вы экспериментируете? Или у вас есть какие-то проблемы\идеи, которые вы хотите решить с помощью BDD?

Вы должны понимать цель и вектор развития автоматизации в проекте в целом для того, чтобы перейти на bdd.

Да возможно, почему нет?! По всему миру так делают и вроде бы получается И вообще, ваш текущий подход и код не сильно пострадает от внедрения BDD. Просто появиться еще один слой кода на page object и все.

Или интересуют конкретные технические ответы на конкретные вопросы, как перейти на jbehave с текущего подхода?


(Шевченко Владислав) #4

Отвечу сразу всем. Заказчик хочет что бы тесты могли писать и мануальщики. Что бы покрыть больше функционала.
Да интересуют подходы перехода. Пока что это отдельный проект с пробами пера.


(Дмитрий Жарий) #5

BDD инструменты не предназначены для такой задачи. Они предназначены для того, чтобы записать пользовательскую историю в наиболее читабельном, коротком и понятном формате, а уж потом, она автоматизируется наиболее эффективным образом.

Наиболее успешный вариант – если пользовательская история записана и автоматизирована теми, кто хорошо разбирается в автоматизации.

Тем не менее, люди пытаются использовать BDD-инструменты как Keyword-Driven фреймворк… и получается не очень. Это требует очень много усилий на поддержку.
Возможно, Keyword-Driven фреймворк – это как раз то, что вам нужно. Т.е. автоматизаторы предоставляют очень высокоуровневые куски кода как «кейворды» – что-то похожее на высокоуровневые методы с параметрами, а мануальщики используют их, просто меняя параметры и последовательность.

  1. Вы можете посмотреть в сторону Robot Framework.
  2. Или создать такие кейворды внутри Java-кода и научить мануальщиков пользоваться и создавать новые тесты.
  3. Можете написать свой парсер для текстового файла с кейвордами.

(Mykhailo Poliarush) #6

Я тоже выскажусь в поддержку, того что сказал @dzhariy. Лучше просто сделать некоторый слой с помощью которого мануальщикам будет проще создавать сами тесты и просто реализовать этот подход. Это могут быть как KDD, так excel, или xml файлы, можете попробовать и BDD чисто ради эксперемента.

Но я бы рекомендовал не выходить за рамки программирования, т.е. чтобы создание тестов автоматизации все таки там и осталось, возможно в более простом виде нежели сейчас есть.

Сделайте небольшие прототипы, дайте пусть мануальщики посоздают тесты, а дальше уже сами решайте. ИМХО, как решите так и будет :smile:

Но не забывайте об этом!

А по поводу технических тонкостей, я думаю, вопрос сильно обширный, вряд ли кто-то напишет детальный ответ. Лучше задавать более конкретные вопросы, что получилось, что нет и так далее.


(Mykhailo Poliarush) #7

Ну и еще приложу пару ссылочек

http://jbehave.org/reference/web/preview/using-selenium.html
http://jbehave.org/reference/web/preview/page-objects.html


(Шевченко Владислав) #8

Сегодня был разговор с заказчиком. В общем цель такова: выбрать тулзу, которая даст возможность снизить стоимость возможных изменений в системе. Имеется ввиду не бизнес логика.
Еще нужно что бы тесты были параметризированы, не просто передачей параметров в тестовый метод. и была возможность запускать тесты с разными данными.

От себя: хочу что б она дружила с TestNG, чем больше у тулзы комюнити - тем лучше. Чувствую что будет нужна помощь в освоении.

Смотрим в сторону JBehave, Fittness, Cucumber. что скажете? Может реально на Robot Framework обратить внимание?


(Александр Таранков) #9

Хочу немного с другой стороны подсказать.

Все эти фреймворки, облегчающие написание тестов - это скользкая дорожка. Она же палка о двух концах, кому как понятнее :slight_smile: О чём я говорю? О том, что идти по этой дорожке нужно очень осторожно. Тот кто на неё ступает должен понимать следующее:

  1. чем больше тестов, тем сложнее их поддерживать
  2. чем ниже уровень тестеров, тем больше тестов
  3. чем проще писать тесты, тем ниже уровень тестеров и больше тестов
  4. чем больше тестов, тем больше ненужных тестов
  5. goto 1

Понятно, да, к чему я клоню? Одно из самых важных, если не самое важное, в автоматизации тестирования - определить что нужно, а что не нужно автоматизировать.

Я не отговариваю вас использовать эти инструменты, просто призываю осмотрительно их использовать и заказчику объяснить эту тему на берегу.

Ваш заказчик не блещет оригинальностью: хочет всё и сразу и TDD и DDT и BDD и чтоб мануальщики это всё писали. А у меня сразу вопрос возникает: а процесс разработки у вас уже настроен идеально? Юнит-тесты пишутся? CI работает? Разработчики со своей стороны всё сделали для того, чтобы снизить стоимость внесения изменений? Это им со своей стороны сделать стоит в разы дешевле и на порядки эффективнее, чем вам со своей.

Неготовность процессов, опять же, не исключает возможности внедрения автоматизации функционального тестирования. Просто сильно снижает её эффективность, как всегда, когда баги обнаруживаются на стороне тестирования


(Дмитрий Жарий) #10

@catchtomorrow, у меня тоже сложилось мнение, что вы (ваш заказчик), хотите решить огромную сложную задачу одним махом.

Так не получится, и ни один инструмент, кроме языка программирования и собственного интеллекта вам не поможет.
Что я рекомендую:

Отбросить задачу «сделать так, чтобы мануальщики писали тесты», и вначале, сделать фреймворк, который бы могла поддерживать небольшая группа людей: 2 – 4 человека. Эти же люди, должны ориентироватся в предметной области продукта.

Эти люди, обязательно должны знать хорошо тот язык програмирования, на котором будут писаться тесты: иметь опыт работы с ООП, владеть хорошими практиками, чтобы не говнокодить.

В такую группу автоматизиторов, если у вас получится, то лучше позвать разработчика, возможно, заманить его печеньками или сделать тех-лидом команды. Но, при этом, это должен быть такой человек, который бы понимал, что его задача – писать простой и эффективный код, и объяснять свои решения другим участникам команды.

Таким образом, создается группа людей, которая разбирается и в продукте и фреймворке автоматизации. И их не пугают «сложности», как мануальщиков.

Второй этап – поверх «сложного» фреймворка, прикрутить инструменты, которыми бы могли пользоваться мануальщики.

К слову сказать, когда вы будете объяснять мануальщикам как пользоваться любым инструментом, они всегда будут жаловаться, «как это все сложно». Просто потому, что в природе человека – противостоять изменениям.

Так что в данной ситуации, по моему мнению, лучше положится на на небольшую группу людей, которые заинтересованы в автоматизации, чем на толпу, которых, “в принципе, и так все устраивает”

Но, это лишь мое мнение, основанное на недостаточном количестве входных данных и личных предположений.

Материалы по теме:

(@catchtomorrow, пожалуйста отпишитесь, если эти ссылки будут для вас полезны и чем именно )


(Zvonov) #11

Солидарен с вышесказанным, все эти сложности с одной стороны суровая действительность, но с другой мы получаем единый репозиторий тестов.

Нет проблем с синхронизацией сценариев мануальных и автотестов. Упрощается поддержка. Автоматизаторы могут выборочно автоматизировать тесты. Неавтоматизированные будут показываться в отчете как пендинг. Прозрачнее картина с общим покрытием.

По сути, неважно какого вида верхний уровень автоматизации. Bdd либо классические сценарии в коде. В хорошо организованном фреймверке разница несущественна.


(Шевченко Владислав) #12

Приняли решение заюзать JBehave все же.

А теперь я хотел бы задать несколько вопросов по реализации и поделиться с какими проблемами сталкиваюсь. ))

Обычный PageObject c базовым классом Page для страниц и TestBase для тестов.

  1. Первая проблема заключалась в том, что использовать аннотации TestNg как раньше в базовом классе (@BeforeMethod в методе SetUp() ) уже не получилось. на смену им пришли @BeforeScenario и т.д.Ну это такое дело. Я так понял что testng с jbehave можно вообще не использовать. Если я не прав - поправьте и научите как это правильно делать.
  2. А вот эта проблема оказалось более критичной. Дело в том что раннее я использовал @ContextConfiguration наследуя AbstractTestNGSpringContextTests базовым классом.
    Дело было примерно так:
@ContextConfiguration(locations = {"file:src/test/resources/context.xml"})
public abstract class TestBase {
    protected Logger l = Logger.getLogger(TestBase.class);
    protected EnvironmentConfiguration configuration;

   @Autowired
   private String application_url;
   @Autowired
   private SimpleDriverDataSource dataSource;

...

Теперь так делать не получается, при выполнении теста контекст не подтягивается т.е. переменная application_url не присваивает значение которое прописано в файле.


(Александр Таранков) #13

JBehave не использовал, но мне кажется, что TestNG тут будет лишний. Поскольку и тот и другой являются по сути test launcher-ами, которые имеют свои правила для разметки и запуска тестов.

Поищите специализированные SpringContext-классы для работы с JBehave, либо более высокоуровневые, если вы хотите конфигурировать тесты через Spring.


(Pavel Gavrilov) #14

Не знаю как в Jbehave. Но например в Ruby есть Cucumber (тоже самое что и Jbehave) так вот в руби он только и есть test launcher - тоесть тесты запускает но не выдает индикации прошел ли тест или нет, нужно использовать дополнительные тестовые фрэймворки для проверки условий например RSpec. Поэтому может в данной ситуации TestNG и не лишний


(sidelnikovmike) #15

Spring в тестах? Мисье знает толк в извращениях.


(Шевченко Владислав) #16

ну это и имел ввиду, не совсем отказ от использования TestNG или JUnit. просто раньше тесты запускал TestNG и управлял я тестами при помощи его аннотаций.


(Zvonov) #17

При желании можно сделать все что угодно, в том числе перенаправлять вызовы лаунчера JBehave на TestNG. Вопрос целесообразности.