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

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