Как правильно написать спецификации запросов в RSpec? - PullRequest
6 голосов
/ 29 января 2012

tl; dr: Перейти к последнему абзацу

Недавно я пытался использовать спецификации запросов RSpec для более целенаправленного тестирования.

Этокак в основном выглядит мое тестирование:

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

Проблема в том, что у меня есть какой-то конкретный сценарий, который вызывает ошибку, и все, кажется, работает на уровне модель / представление, где я не могувоспроизвести это.

Это вынуждает меня написать интеграционный тест, который я также могу сделать в огурце.Проблема возникает, как только я могу воспроизвести ее, и мне нужно выяснить, почему это происходит.Обычно это означает играть в тестах, менять разные вещи и видеть, что происходит.

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

На данный момент, я предпочитаю писать спецификации запроса, потому что это более низкий уровень и позволяет мне напрямую делать вещи.Проблема в том, что я не совсем уверен, как правильно написать спецификацию запроса или каковы правила.

Простой пример здесь:

visit login_path
fill_in "Username", :with => user.username
fill_in "Password", :with => user.password
click_button "Log in"

против

post sessions_path(:username => user.username, :password => user.password)

или даже что-то более низкое, например

session[:user_id] = user.id # this actually doesn't work, but the idea is there

Оба этипримеры достигают того же самого, они регистрируют пользователя. Я знаю, что ответ, который нужно выбрать, основан на том, что мне нужно проверить, но это не дает правильного, обычного способа сделать это.

Я пытался найти кое-что о спецификациях запросов, но они нигде не описаны. Книга RSpec не охватывает их, документация RSpec тоже ничего не говорит.

Как правильно написать спецификации запроса?Когда я должен использовать капибару и когда только методы Rails #get и #post вместо нажатия кнопок и visit путей ввода?

Ответы [ 2 ]

3 голосов
/ 09 февраля 2012

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

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

Как уже упоминалось в комментариях, вы должны протестировать поведение конкретного контроллера / представления в других типах спецификаций.

0 голосов
/ 18 января 2013

Первая проповедь ....

Я думаю, что естественный прогресс ВАС, автора теста, звучит:

  1. Контроллер
  2. Модель
  3. Запросы
  4. смесь спецификаций запросов, контроллеров и моделей.

Я знаю, что сначала начал смотреть на контроллер, потому что его было легче понять.

Затем вы попадаете в спецификации моделей для вещей, не связанных с радостью ...

Затем вы понимаете, что rspec на самом деле не отображает представление, поэтому вы начинаете видеть глупые ошибки в Airbrake, так что вы говорите: стреляйте ... Мне нужно проверить представления и рабочий процесс. Следовательно запрос спецификации.

Наконец, вы становитесь старше и понимаете, что все 3 важны и должны использоваться экономно, но соответственно. Сейчас я только на шаге 4 ... слишком много спецификаций запросов, и вы тратите 5 минут на весь пакет в приложении среднего размера. отстой.

Чтобы ответить на ваш вопрос:

Я тестирую рабочий процесс и представления, которые мне нужно "увидеть" (с page.should или любым хитрым JS (например, jquery ui селекторы) с капибарой в спецификации запроса.

Если мне просто нужно убедиться, что переменные контроллера созданы, или сделать что-то быстрое с постом для неудовлетворительного пути, вне рабочего процесса ... Я использую контроллер. Например, POST для контроллера IPN в PayPal ...

Вы были бы удивлены, насколько это покрывает. Таким образом, вы можете протестировать модели на предмет всех отбитых вещей, которые вам понадобятся для всех крайних случаев.

Честно говоря, я бы сказал, использовать Fixtures и Test Unit для интеграционных тестов ... они все еще нравятся лучше, быстрее ... сильнее ... и т.д.

...