Переход на Cucumber в существующем фреймворке

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

Второй проект работаю с БДД. Вначале был на Java+Cucumber+Junit, теперь на c#+SpecFlow+NUnit. Начинал писать с 0 тесты. Плюс, что понятно, что падает, на каком степе, все степы разделены по page обьектам. Allure смог недавно прицепить в .Net только. Но знаю, что есть и Allure for Cucumber.
По поводу вашей ситуации, думаю проще будет начать новый проект. Перекинуть туда PageObjects, и брать часть методов и вставлять в степы.

#11

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

ЗЫ:
А уж читая примеры на Cucumber JVM, я вспоминаю как это это сделано на Cucumber JS (там тоже есть свои боли, но по крайней мере степы писать гораздо проще).

Сравните код для Cucumber JVM:

@Given("I have {int} cukes in my {string}")
public void some_cukes(int howMany, String what)
    // some code
}

С этим же кодом для JS

Then(/^I have (\d+) cukes in my (.*)$/, function (howMany, what) {
    // some code
}

Как минимум, для Cucumber JVM придется придумывать метод some_cukes, для того же JS - степом будет функция Then() с переданной ей регуляркой. Пишется гораздо быстрее и легче (текст из Gherkin легко ложится в код).

#12

(в качестве небольшого оффтопа) В Cucumber-JVM не так давно завезли лямбды, так что там тоже можно писать методы как в JS (непонятно правда, зачем, и какой от этого профит, но тем не менее):

        Then("^I have (\\d+) cukes in my (.*)$", (Integer howMany, String  what) -> {
            // some code
        });
3 лайка
#13

Это вообще не слои.

У вас есть слой пейдж обжекта, скорей всего слой степов (алюр) Сверху накладываете еще 1 слой геркина и всё, то что написано у вас в степах Алюра просто напишите на геркине.
У нас серенити и на 1 слой больше. Слой пейджей -> слой степов серенитики -> слой степов на jBehave -> слой на геркине.

#14

Единственная польза от внедрения Cucumber на проекте - это то, что понятие тест кейс существует в единственном экземпляре в виде gherkin сценария. Если у вас по прежнему останется тест кейс в какой либо тест трекинговой системе и ещё один в виде gherkin сценария, то смысла очень мало.

Незначительный профит можно получить если вы планируете процедуру приемки автотестов тестировщиками - т.е. процедура когда тестировщик мануальный убеждается что автотест выполняет всё как задумано - на gherkin всё понятней.

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

1 лайк
#15

Не знаю как на Java, но на C# в Specflow можно использовать любой тестовый фреймворк для генерации и выполнения тестов, хотя сами тесты пишутся на геркине. Потом можно просто запустить таким образом:

nunit3-console bin\Debug\UnitTestProject2.dll

При таком подходе вы можете дописывать тесты в новом формате в существующий фреймворк, переиспользуя всю инфраструктуру(Page Objects…)

1 лайк
#16

Что бы понять подходит вам или нет этот подход надо просто попробовать. Это ведь займет не так уж много времени. И потом вы сами сможете предоставить отчет начальству со всеми плюсами и минусами. Боятся внедрять что-то новое это путь в никуда… Со стороны заказчика преимущества этого подхода очевидны он сможет прочесть и понять что вы делаете.

#17

Если начальству нужны только красивые/понятные отчеты, и ничего более - лучше реализовать нормальное логирование в отчете, нежели чем внедрять BDD.

1 лайк
#18

Как насчет такого варианта :

@Slf4j
public class StepLog {

    @Step("Given {stepDescription}")
    public static void Given(String stepDescription) {
        log.info("Given " + stepDescription);
    }

    @Step("When {stepDescription}")
    public static void When(String stepDescription) {
        log.info("When " + stepDescription);
    }

    @Step("Then {stepDescription}")
    public static void Then(String stepDescription) {
        log.info("Then " + stepDescription);
    }

    @Step("And {stepDescription}")
    public static void And(String stepDescription) {
        log.info("And " + stepDescription);
    }

    @Step("I {stepDescription}")
    public static void I(String stepDescription) {
        log.info("I " + stepDescription);
    }
}

В тестах пишете логи в подобном формате и показываете заказчику отчет в “BDD” style. Или они хотят писать тоже ?

1 лайк
#19

Не сказал бы что это что-то новое) Сделать пилот не сложно, но при попытке его интегрировать в существующий фреймворк только на подготовку уйдет прорва времени, при очень ограниченных ресурсах (этак 0.5 меня) :slight_smile:

#20

Логирование (и репортирование происходят по @Step, в лог попадает начало и конец выполнения степа) и так нормальное :slight_smile: по это дело и писали фреймворк, с логированием (и репортированием) степов чуть ли не до кликов. Новый начальник пришел и тулит отчет из кукумбера, как “крутой” сравнивать его с аллюровским вообще смешно.

#21

Выяснилось что заказчик хочет BDD как процесс разработки, остальное это наш новый менеджер, у которого на прошлом проекте был успешный для него кукумбер… вот и несет свет в массы.

#22

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

1 лайк
#23

Господа, немного оффтоп, но направьте пожалуйста на вменяемые примеры или гайды управлением тестов в данном замечательном фреймворке. Тоесть реализованную систему запуска тестов поштучно, группами итд… для привыкших работать в TestNG

#24

Tag’и развешиваете и будет счастье

#25

Счастье похоже не в этой теме :slight_smile:
Тагами можно определить какой набор сценариев запускать… типа по разному функционалу, санити, регрессия итд… тут понятно. Нужно запустить тестовый класс сконфигурированный тагами на запуск чего-то.
Но вопрос в другом как иметь возможность запускать сценарии поштучно? (требование менеджера)? Ведь под каждый сценарий сделать тестовый класс это какой-то феерический бред…

#26

Так вешайте несколько тегов на сценарии (я про фиче-файлы). Если на каждый сценарий вешать уникальный тэг, например, номер/ид теста в алм системе, то потом можно запустить этот сценарий «штучно», при этом, если тэгов несколько, то можно как штучно запускать, так и согласно какой-то классификации.
https://docs.cucumber.io/cucumber/api/

2 лайка
#27

А можете пример привести неуспешного проекта на Cucumber. И почему вы решили что он не успешен ?

#28

Учтите если будете вызывать методы с аннотацией @Step в другом методе класса, содержащий Step Definitions, то в Allure Report, сгенерированный Cucumber Adapter-ом, то они будут отображаться как саб-степы, под-тесты, часть одного шага.

#29

Так а я не использую cucumber - я использую обычный Junit 5, а степы у меня просто в таком виде в самом тесте прописаны. Это методы которые логируют степы и в аллюр красиво записываются. На выходе у меня есть полный лог приатаченый к репорту + все степы описаны в отчете в виде BDD

1 лайк