Повторное использование шагов огурца в большой кодовой базе / команде - PullRequest
0 голосов
/ 09 февраля 2019

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

Поскольку все шаги в Cucumber являются глобальными, написать довольно сложношаги типа «и я выбираю первый элемент в списке» или аналогичные, которые были бы аналогично высокоуровневыми.Мы заканчиваем тем, что добавляем «на домашней странице» (то есть: «Я выбираю первый элемент в списке папок на домашней странице»), который просто кажется неправильным и читает неправильно.

Кроме того, мне очень трудновыяснить, каковы зависимости между шагами.Например, мы используем шаблон «и я вижу» для хранения ссылки на объект страницы в экземпляре огурца world, который будет использоваться на некоторых последующих этапах.Я нахожу это очень неловким, поскольку эти зависимости практически незаметны при чтении файлов .feature.

Что вы посоветуете, как использовать огурец в большой команде?(Включая "огурец из канавы и используй вместо этого" :))

1 Ответ

0 голосов
/ 10 февраля 2019

Напишите сценарии / шаги, которые касаются того, что вы делаете и почему вы делаете это, а не о том, как вы делаете вещи.Огурец - это инструмент для ведения BDD.Ключевое слово здесь - Поведение и его интерпретация.Основная идея Cucumber и шагов заключается в том, что каждый элемент поведения (что) имеет уникальное имя и место в приложении, и в контексте приложения вы можете говорить об этом поведении, используя это имя без двусмысленности.

Так что ваши примеры никогда не должны идти поэтапно, потому что они о том, КАК вы что-то делаете.Хорошие шаги никогда не говорят о нажатии или выборе.Вместо этого они говорят о причине, по которой вы нажимаете или выбираете.

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

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

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

Scenario: Login
  Given I am registered
  When I login
  Then I should be logged in

Реализация этого интересна тем, что я делегирую всю работу вспомогательным методам

  Given I am registered
    @i = create_registered_user
  end

  When I login
    login_as(user: @i)
  end

  Then I should be logged in
    should_be_logged_in
  end

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

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

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

Вы можете делать все это с помощью дисциплины именования (все мои методы выше имеют вход вих имя) - умное, но контролируемое использование аргументов - частое рефакторинг и очистка кода

Код ваших вспомогательных методов будет иметь - наибольший отток из всего кода вашего приложения - самая большая потребность быть простой и понятной

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

...