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

Question

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

Итак, как пользовательский интерфейс вписывается в это?

Заимствование одного из Норта blog entries, он переписывает это:

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 

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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