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

webdriver
,
#1

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

#2

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

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

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

2 лайка
#3

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

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

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

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

#4

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

#5

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

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

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

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

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

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

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

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

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

2 лайка
#7

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

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

1 лайк
#8

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

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

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

#9

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

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

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

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

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

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

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

5 лайков
#10

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

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

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

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

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

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

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

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

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

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

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

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

4 лайка
#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.

#14

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

#15

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

#16

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

#17

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