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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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