TDD/BDD Rails Дублирование огурца/RSpec

Может ли кто-нибудь прояснить, используя историю пользователей SIMPLE, полный фрагмент того, что будет использовать Cucumber и для чего будет использоваться RSpec? На днях я купил книгу RSpec и проходил через нее. Время от времени автор кажется довольно расплывчатым.

Что я думаю о том, что пользовательская история - это что-то вроде этого (пожалуйста, извините за неправильность синтаксиса, это просто потому, что вы поняли суть):

Когда пользователь вводит неверный номер телефона затем они получают сообщение с сообщением "Недопустимый номер телефона"

Если я выписал весь код для Cucumber, чтобы проверить это, а затем написать материал rspec, я в основном дублирую свой тест. Есть ли сценарий, объясняющий, как тест огурца должен отличаться от теста rspec?

Я чувствую, что вы будете дублировать тесты на обоих уровнях все время.

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

Пожалуйста, помогите. Я чувствую, что моя голова вот-вот взорвется.

Спасибо!

ОТВЕТЫ

Ответ 1

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

Итак, тесты IMHO Cucumber (истории) не заменяют тесты rspec.

Тесты RSpec, как правило, способствуют разработке моделей и контроллеров, и истории, как правило, способствуют разработке представлений.

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

Ответ 2

Возможно, было бы полезно посмотреть на скринкасты в BDDCasts.com. Они проводят вас через создание рассказов и спецификаций для приложения. Это действительно помогло мне. Кроме того, они владеют rspec-книгой, но все еще смущены. Возможно, вы даже захотите просто проверить свой источник на github.

Для меня это происходит следующим образом:

  • Огурец, чтобы проверить, что увидит пользователь. (Полный тест стека)

  • Rspec проверить все остальное. (Модель, контроллер)

Ответ 3

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

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

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

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

Feature: Search users
  In order to find people with similar interests as myself
  As a user
  I want to search for people

Scenario: Search for similar hobbies
  Given there is a search page
    And there is a list of hobbies
    And one of the hobbies is "full contact ironing"
   When I select "full contact ironing"
    And press search
   Then a list of users with the hobby "full contact ironing" are shown

Вы запускаете Cucumber, он сообщает вам, какие шаги вам не хватает, вы копируете их и создаете простые шаги, чтобы проверить этот материал, но еще не писать код.

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

describe "SearchController" do

  it "should respond to searches" do
    sc = SearchController.new
    sc.should respond_to(:search)
  end

end

Вы запускаете RSpec и смотрите, как он терпит неудачу, затем выключите и напишите свой код:

class SearchController

  def search
  end

end

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

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

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

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

Ответ 4

Rspec и Cucumber независимы, и вы можете использовать Cucumber и другую тестовую среду для своих тестов (Test Unit, shoulda и т.д.).

Дело в том, что вы хотите протестировать с огурцом? Потому что действительно вы могли бы закончить дублирование тестов, и это было бы не очень полезно, не так ли?:)

Существуют разные философии с огурцом.

С помощью огурца вы можете:

DMA (прямое значение доступа к модели, да, вы можете полностью протестировать свою модель, как в rspec)

Имитированный броузер (доступ ко всему стеку MVC, без javascript)

Автоматический браузер (используйте webrat и selenium для доступа к вашим представлениям, с javascript, медленным, реальным броузером)

Мне нравится делать огурец, чтобы проверить, что возвращается пользователю. Обычно это имеет смысл для меня, когда я определяю свои рассказы, так как я не имею в виду код, который я собираюсь написать. Поэтому я тестирую конечный результат с помощью Cucumber → views (с использованием имитированного или автоматизированного бровей)

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

Таким образом, в вашем случае

Когда пользователь вводит неверный номер телефона, он получает сообщение "Недействительный номер телефона"

Я бы использовал Webrat, чтобы проверить, что пользователь получил сообщение "Недействительный номер телефона" в представлении. Я бы использовал Rspec для проверки моего действия и модели контроллера.

Ответ 5

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

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

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