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

Когда мне следует использовать спецификации для Rails-приложения и когда Cucumber (прежние rspec-story)? Я знаю, как и работать, и активно использовать спецификации, конечно. Но все еще странно использовать огурец. Мой текущий взгляд на это заключается в том, что удобно использовать Cucumber, когда вы реализуете приложение для клиента, и пока не понимаете, как должна работать вся система.

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

И, как соответствующий второй вопрос: должен ли я писать спецификации, если я пишу истории о огурцах? Не будет ли двойное тестирование одного и того же?

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

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

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

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

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

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

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

История с Cucumber - это скорее описание общей проблемы, которую решает ваше приложение, а не то, как работают отдельные кусочки кода (например, модульные тесты).

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

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

1. Напиши свою историю
2. Используя RSpec, я бы создал интеграционный тест, например: spec / integrarations / socks_rspec.rb
3. Затем я бы создал интеграционный тест, включающий новое описание и блок для каждого сценария.
4. Затем я реализовал бы минимальную функциональность, необходимую для тестирования интеграции, и, углубляясь назад (в контроллеры, модели и т. Д.), Я бы применил TDD для контроллеров и моделей.
5. Когда вы вернетесь, ваш интеграционный тест должен пройти, и вы сможете продолжить добавлять шаги в интеграционный тест.
6. повторение

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

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

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

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

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