Когда мне следует тестировать виды отдельно в рабочем процессе Cucumber & RSpec? - PullRequest
Новая
       21

Когда мне следует тестировать виды отдельно в рабочем процессе Cucumber & RSpec?

7 голосов
/ 16 декабря 2010

После некоторого времени работы с Cucumber & RSpec BDD я понял, что многие из моих функций Cucumber - это просто тесты просмотра более высокого уровня.

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

Возьмите этот сценарий, например 

Scenario: New user comes to the site
  Given I am not signed in
  When I go to the home page
  Then I should see "Sign up free"

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

Я неправильно подхожу к огурцу? Что именно я должен проверить в спецификации?

Должен ли я писать их для каждого отдельного представления, например, для проверки представлений для таких действий, как 

def show
  @project = current_user.projects.first
end

или мне просто проверить более сложные представления?

Ответы [ 3 ]

8 голосов
/ 16 декабря 2010

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

Я утверждаю, что «читабельный» аспект Cucumber делает некоторые аспекты видоискания важными.Например, я нахожу, что спецификации вида работают очень хорошо при параллельной работе с внешним разработчиком.Если разработчик JavaScript знает, что он захочет подключить селектор на вашей странице, важно, чтобы ваше представление предоставило этот селектор.

Например: 

describe 'gremlins/show.html.haml' do
  context 'given it is after midnight' do
    it 'has a #gremlin_warning selector' do
      Time.stub!(:now).and_return(Time.parse '2010-12-16 00:01:00')
      rendered.should have_selector '#gremlin_warning'
    end
  end

  context 'it is before midnight' do
    it 'does not have a #gremlin_warning selector' do
      Time.stub!(:now).and_return(Time.parse '2010-12-16 23:59:00')
      rendered.should_not have_selector '#gremlin_warning'
    end
  end
end

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

tl; dr : Просмотр спецификации предназначен для передачи контракта другим разработчикам и должен использоваться экономно (но, тем не менее, следует использовать).

2 голосов
/ 16 декабря 2010

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

0 голосов
/ 19 апреля 2011

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

...