RSpec против Cucumber (истории RSpec)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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