RSpec Stories и Specs: когда и что использовать?

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

На мой взгляд, характеристики вида, контроллера и модели - это только часть картины. Они говорят на языке реализации («действие контроллера X должно делать Y для модели Z») и проверяют, что каждая часть вашего приложения делает правильные вещи. Истории дополняют картину, говоря на языке пользователя («когда я публикую комментарий, я должен увидеть комментарий, который я оставил») и проверяя, что детали соответствуют друг другу таким образом, чтобы соответствовать критериям приемлемости клиента.

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

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

Таким образом, история может помочь вам в том, что ваши спецификации должны проверить.

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

Answer 3

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

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

Answer 4

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