Разработка на основе поведения с использованием существующих программных компонентов

Question

В настоящее время я читаю бета-версию The Rspec Book: http://www.pragprog.com/titles/achbd/the-rspec-book

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

Мой вопрос:

Если бы мне пришлось описать одну особенность моего программного обеспечения (например: сценарий успешного входа пользователя в тест на огурец) Иесли бы я использовал модульный компонент (например, Devise), который имеет много функций (сценариев).Как я мог следовать методам, управляемым поведением?Как только мой первый шаг пройден, я должен перепроектировать другие мои тесты, чтобы отразить функциональность программного компонента, который я использую, таким образом нарушая принцип BDD!

Редактировать (для ясности):

МойПервый сценарий проходит после реализации Devise.Но теперь я должен учесть все свои последующие сквозные тесты (которые я еще не написал) вокруг поведения Devise, а не требований моего заинтересованного лица.Таким образом, цикл BDD больше не может быть применен.Я должен перепроектировать Devise в моих тестах, чтобы заставить их пройти или не писать тесты.

Answer 1

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

Если вы используете BDD-инструмент, такой как Cucumber, вы можете записать сценарии, которые вы обсуждали.

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

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

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

Given I have registered an account
When I <do this differentiating thing>
Then I <achieve this differentiating outcome>

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

Answer 2

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

Given a visitor is not logged in
When a visitor goes to the admin page
Then the visitor should see the login page

Хорошо, тогда вы решаете, как вы хотите реализовать логин, потому что этот сценарий не выполняется.Правильно?Таким образом, вы выбираете Devise, и сценарий проходит, но все тесты или спецификации, которые полагались на систему без защиты, теперь терпят неудачу.Я все еще на ходу?Если это так, вы столкнулись со случаем, когда вы добавляете функцию, которая настолько распространена в вашем приложении, что вам нужно коснуться ряда тестов / спецификаций, чтобы запустить их все.Сначала вы все еще тестируете, потому что либо код не работает, либо тест не распознает новую функцию.В любом случае, вы знаете, где должна быть выполнена работа.

Полезно?