RSpec Истории и характеристики: когда использовать что?

Итак, я хочу начать использовать рассказы RSpec, но я не уверен, где вписываются спецификации контроллера, модели и представления.

Например, у вас есть история "Вход в систему" с сценарием "Пользователь предоставляет неправильный пароль", не закончите ли вы тестировать те же материалы, что и спецификации контроллера/модели (response.should render..., user.should be_nil и т.д.)

Итак, мой вопрос: для тех, кто привык делать bdd (или историю dd) с RoR, вы все еще пишете спецификации модели/контроллера? Если да, то каков рабочий процесс, который вы следуете ( "первая история, а затем узкая для конкретных спецификаций" )?

Ответ 1

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

Самый простой способ разделения между спецификациями и историями - использовать истории для полного тестирования бизнес-требований и спецификаций для изолированных низкоуровневых спецификаций компонентов (представлений, помощников, контроллеров и моделей). "Полный стек" может варьироваться от контроллера/модели/базы данных до моделирования клиента с помощью Webrat для тестирования в браузере с помощью Watir или Selenium.

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

Ответ 2

Я считаю, что истории полезны, когда они проверяют поведение, которое пользователь фактически выполняет или наблюдает, - вместо того, чтобы проверять, что визуализирован шаблон "неудачного входа", проверьте, что ответ содержит "не удалось войти в систему". ИМХО это лучше, если истории никогда не относятся к моделям, представлениям или контроллерам напрямую, хотя иногда бывает трудно заставить эти шаги работать без создания экземпляров модели вручную.

Как я вижу, спецификации просмотра, контроллера и модели являются лишь частью изображения. Они говорят на языке реализации ( "действие контроллера X должно делать Y для модели Z" ) и проверять, что отдельные части вашего приложения работают правильно. Истории завершают картину, говоря языком пользователя ( "когда я отправляю комментарий, я должен увидеть комментарий, который я разместил" ), и проверяя, что детали соответствуют друг другу таким образом, который соответствует критериям приемлемости клиента.

Я нашел полезный рабочий процесс:

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

Таким образом, история может помочь вам узнать, что вам нужно проверить.

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

Ответ 3

Пэт Мэддокс (основная команда RSpec) считает, что при некоторых предположениях вы можете пропускать спецификации контроллера при использовании рассказов/функций огурца

Прочитайте о его точке зрения здесь

Ответ 4

Как насчет пропустить представление, если у вас есть огурец + каппибара. Я, как правило, не вижу, что спецификация вида не нужна.