Подтвердить что ты не робот

Действительно ли BDD применим на уровне пользовательского интерфейса?

BDD - это "внешняя" методология, которая, как я понимаю, означает, что вы начинаете с того, что знаете. Вы пишете свои истории и сценарии, а затем реализуете самые внешние объекты домена, перемещая "внутрь" и "намеренно" обнаруживая соавторов, когда вы идете вниз по уровням услуг, уровням домена и т.д. Для того, кто еще не существует, вы издеваетесь над ним (или "подделываете" ), пока не сделаете это. (Я краду некоторые из этих терминов прямо из Дэн-Норт и Кент Бек).

Итак, как UI вписывается в это?

Заимствование из одного из записей записей в блоге, он переписывает это:

Given an unauthenticated user
When the user tries to navigate to the welcome page
Then they should be redirected to the login page
When the user enters a valid name in the Name field
And the user enters the corresponding password in the Password field
And the user presses the Login button
Then they should be directed to the welcome page

в это:

Given an unauthenticated user
When the user tries to access a restricted asset
Then they should be directed to a login page
When the user submits valid credentials
Then they should be redirected back to the restricted content

Он делает это, чтобы исключить язык из необязательных доменов, одним из которых является пользовательский интерфейс ( "поле имени", "поле пароля", "кнопка входа" ). Теперь пользовательский интерфейс может измениться, и история (точнее, намерение истории) не сломается.

Итак, когда я пишу реализацию для этой истории, я использую пользовательский интерфейс или нет? Лучше ли запускать браузер и выполнять "пользователь представляет действительные учетные данные" с помощью теста Selenium или напрямую подключиться к базовой реализации (например, службе проверки подлинности)? Кстати, я использую jBehave в качестве моей рамки BDD, но так же легко можно было бы использовать Cucumber, rSpec или несколько других.

Я стараюсь не тестировать пользовательский интерфейс в автоматическом режиме, и я осторожно отношусь к инструментам автоматизации графического интерфейса, таким как Selenium, потому что я считаю, что тесты (1) могут быть слишком хрупкими и (2) запускаться там, где стоимость исполнения наибольший. Поэтому моя склонность - вручную протестировать пользовательский интерфейс для эстетики и удобства использования и оставить бизнес-логику более легкими, более легко переносимыми слоями. (И, возможно, слои с меньшей вероятностью могут измениться.)

Но я открыт для обращения к этому. Итак, BDD для пользовательского интерфейса или нет?

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

4b9b3361

Ответ 1

Большинство пользователей, использующих автоматизированные инструменты BDD, используют его на уровне пользовательского интерфейса. Я видел, как несколько команд переносят его на следующий уровень вниз - уровень контроллера или презентатора - потому что их пользовательский интерфейс изменяется слишком часто. Одна команда автоматизирована из пользовательского интерфейса на своем сайте, ориентированном на клиента, и с контроллера на админ-сайте, поскольку, если что-то было сломано, они могут легко исправить его.

В основном BDD разработан, чтобы помочь вам иметь четкие, недвусмысленные беседы с вашими заинтересованными сторонами (или помочь вам обнаружить места, где неоднозначность все еще существует!) и переносить язык в код. Разговоры гораздо важнее, чем инструменты.

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

Я бы сказал, если ваш пользовательский интерфейс стабилен, попробуйте автоматизацию, и если это не сработает для вас, либо опуститесь на более низкий уровень, либо убедитесь, что у вас достаточно ручного тестирования. Если вы все равно тестируете эстетику, которая поможет (и никогда не будет использовать автоматизацию для тестирования эстетики!) Если ваш пользовательский интерфейс нестабилен, не автоматизируйте его - вы просто добавляете приверженность тому, что вы знаете, вероятно, собираетесь изменение и автоматизация в этом случае усложнят работу.

Ответ 2

Я новичок в BDD, но я нашел сайт cuke4ninja, чтобы помочь в этом отношении. То, что они предлагают (моя интерпретация), заключается в том, что у вас есть определения шага, которые являются высокоуровневыми и несовместимыми с пользовательским интерфейсом, который вызывает класс "рабочий процесс", который группирует такие детали, как "нажмите эту кнопку", "заполнить это поле" в методе, который захватывает тестируемый рабочий процесс, который вызывает класс "экранный драйвер", который обрабатывает автоматизацию пользовательского интерфейса для этого конкретного экрана. Таким образом, весь код автоматизации пользовательского интерфейса абстрагируется от определений шагов и находится в одном месте, и если пользовательский интерфейс изменяется, вам просто нужно изменить код в "экранном драйвере" вместо всех нескольких тестов. Здесь - соответствующая страница, на которой она обсуждается.

Ответ 3

Что описывает BDD?

В командах, следующих за поведенчески-ориентированной разработкой (BDD), Критерии приемки (правила) должны описывать "что система делает" вместо "как система это делает".

Итак, где же фиксируются детали UI/UX?

В командах, использующих BDD, детали слоя "Интерфейс пользователя (UI)" и "Пользовательский опыт" (кнопки, щелчки и т.д.) Не должны включаться в текстовый формат под заявкой (например, выпущенной с помощью инструмента Software Ticketing Tool, такого как JIRA, GitLab и т.д.).). Вместо этого они должны быть включены в экраны дизайна (каркасы, путешествие пользователя, отдельные экраны и т.д.). Например, текстовые заметки могут быть встроены в экраны дизайна с аннотациями или просто как комментарии рядом с экранами.