RSpec против огурца (рассказы RSpec)

Ответ 1

Если вы еще этого не сделали, вы можете проверить отличную статью Dan North, Что в истории? в качестве отправной точки.

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

В нашей работе Rails истории Cucumber не заменяют модульные тесты rspec. Эти два идут рука об руку. На практике модульные тесты, как правило, способствуют разработке моделей и контроллеров, и истории, как правило, способствуют разработке представлений (мы склонны не писать rspec для наших представлений) и обеспечивают хороший тест приложения в целом из пользователя.

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

Ответ 2

Подумайте об этом как о цикле:

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

Ответ 3

Мое мнение состоит в том, что плохая идея использовать Cucumber в большинстве ситуаций из-за затрат на производительность, которые синтаксис на вас терпит. Я много писал о теме в Зачем беспокоиться о тестах на огурцы?

Ответ 4

Рассказ огурца - это скорее описание общей проблемы, решаемой вашим приложением, а не работы отдельных битов кода (т.е. модульных тестов).

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

Ответ 5

В настоящее время вы можете использовать rspec с Capybara и Selenium Webdriver и избегать создания и поддержки всех парсеров истории огурца. Вот что я бы рекомендовал:

• Напишите свою историю
• Используя RSpec, я бы создал интеграционный тест ex: spec/integrations/socks_rspec.rb
• Затем я бы создал интеграционный тест, который включает в себя новое описание и блок для каждого сценария
• Тогда я бы выполнил минимальную функциональность, чтобы получить тест интеграции и, углубляясь назад (в контроллеры и модели и т.д.), я бы TDD на контроллерах и моделях.
• Когда вы вернетесь, ваш интеграционный тест должен пройти, и вы можете продолжить добавлять шаги к тесту интеграции.
• повторить

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

Кроме того, как только вы найдете свой паз, вы найдете его наиболее приятным для разработки с использованием BDD, до тех пор не чувствуете себя виноватым, если вы не чувствуете, что делаете это идеально и не передумаете. Вы отлично поработаете!

Ответ 6

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

Вам все еще нужен огурец. Вам нужно документировать, как вы видите работу системы, и вам нужно, чтобы вы не нарушили функциональность, когда вы меняете вещи.

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