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 действительно предназначен для решения небольших бит поведения и делает все очень дискретным. Если вы знакомы с модульным тестированием и фреймворками для этого, это должно иметь больше смысла.
Утилита огурца может переводить описания высокого уровня в набор действий верхнего уровня в системе.
Ответ 6
Эта статья может дать вам некоторую перспективу: Когда повторять себя в тестах - и когда не до