Java Cucumber: создание сценариев с динамическими примерами

Question

У нас есть тест, в котором нам нужно ввести определенное значение на веб-сайте и убедиться, что получено другое значение.Данные ввода-вывода для этого хранятся в файле XML.

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

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

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

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

Answer 1

Фреймворк NoraUi делает именно то, что вы хотите сделать в своем проекте.Код NoraUi с открытым исходным кодом.Если у вас есть вопросы об этой платформе, вы можете опубликовать вопрос с тегом «Вопрос»

Answer 2

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

В какой-то момент в вашем коде, после того как пользователь введет свое значение, значение будет передано методу / функции, которая вернет ваш ответ,Это место для такого рода тестирования.

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

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

Cuking должен иметь примерно один счастливый путь (пользователь может ввести значение и увидеть результат) и, возможно, грустный путь (пользователь вводит неправильное значение и видит ошибку /объяснение).Все остальное нужно отодвинуть до юнит-тестов.