TDD / BDD Rails Огурец / дублирование RSpec - PullRequest
12 голосов
/ 09 ноября 2009

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

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

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

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

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

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

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

Спасибо!

Ответы [ 6 ]

13 голосов
/ 09 ноября 2009

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

Для меня это выглядит так:

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

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

12 голосов
/ 09 ноября 2009

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

Итак, тесты IMHO на огурец (истории) не заменяют тесты RSpec.

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

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

6 голосов
/ 03 декабря 2010

Представьте, что 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 и сказать, как я хочу, чтобы эта функция действительно работала.

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

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

5 голосов
/ 09 ноября 2009

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

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

Есть разные философии с огурцом.

С огурцом вы можете сделать:

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

Имитация браузера (доступ ко всему стеку MVC, без JavaScript)

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

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

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

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

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

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

2 голосов
/ 09 ноября 2009

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

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

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

0 голосов
/ 15 мая 2010

Эта статья может дать вам некоторое представление: Когда нужно повторяться в тестах, а когда нет

...