Выбор инструмента для автоматизации или стоит ли использовать BDD?

инструменты
, , ,
#1

Помогите с выбором инструмента для “разжевывания” сценариев для автоматизации.

Стоит задача парсить сценарии из тест-трекера, т.е. грубо говоря есть сценарий вида:

Шаги / результат

  1. Пользователь авторизовывается / открывается главная страница
  2. Нажимает на кнопку Меню / открывается меню, есть такие-то элементы
  3. Выбирает такой-то элемент / Выполняется такое-то действие

или

Шаги / результат

  1. Отправляется запрос getA / получен ответ с параметрами, есть все параметры, параметр A1 = false
  2. Отправляется запрос getB, в котором B0 = A1 / получен ответ с параметрами, есть все параметры B1 = true

Первое что приходит в голову cucumber, ранее был опыт использование, но очень давно, и в целом, сейчас читаю разные мнения, и они протеречивы. Как вариант, использовать другие инструменты BDD - JBehave, RobotFramework.

Что выбрать? Тесты пишутся на java. Первоочередная задача покрыть тестами API.

#2

Стесняюсь спросить, а в сторону Cucumber не смотрели?
У нас сейчас похожая задача.

http://thucydides.info/docs/articles/an-introduction-to-serenity-bdd-with-cucumber.html

#3

просто оставлю тут

#4

Про cucumber писал выше, мне кажется не самый гибкий из возможных вариантов, смотрите на исходную задачу

#5

Как и писал выше, читал статью, и, к удивлению, процессы уже выстроены подобным образом. Дельные советы есть?

#6

Используйте cucumber и не парьтесь. Сами на нём сейчас сидим.

#7

Не поделитесь впечатлениями?

#8

А огурец для какого ЯП?

#10

Java, Groovy

#11

Что конкретно интересует?

#12

Удобство, скорость, наличие костылей, используете ли тест-трекер для выгрузки тест-кейсов

#13

Удобство. Трудно оценить. Достаточно удобно. :slight_smile: Ну знаю в чём мерять.
Скорость чего? Как обычно никаких, каких-то тормозов связанных с ним не замечено.
Костыли. Мы расширили немного классы для работы с табличными данными. Типа удаление колонок, парсинг из стрингового типа в нужный и так далее. Сам framework не допиливали. Хотя нет! Наш разработчик поднимал pull request на github для добавления множества классов World. Ещё в 2014 году. :slight_smile:
Тест-трекера у нас нет. Храним вместе с кодом в гите.

#14

Я в своей команде использую BDD, (в Python) для создания длительных интеграционных/функциональных тестов (от 30 до 4-х часов). Сейчас используем lettuce (последние 3 года), но планируем либо писать свое, либо переходить на aloe/behave, хотя у нас есть к ним вопросы. Мы за пару лет написали уже кучу степов и чаще всего, написание нового тест кейса (feature файла) занимает 20 минут на общение с разработчиком и 20 минут на накидывание степов в файл. Тестируем мы достаточно сложное клиент-серверное приложение.

Я бы рекомендовал саму BDD методологию на достаточно сложные вещи, которую надо показывать кому-то, кто не смыслит в коде. К тому же, по моему опыту, он совсем не подходит на тестирование unit функционала, т.к. описывать что сделать, дольше, чем писать unit теста