Должен ли я использовать RSpec или огурец

Question

Я новичок в модульном / функциональном тестировании в Rails 3. Итак, я начинаю сейчас, лучше поздно, чем никогда.

У меня есть метод в /lib/mailingjob.rb, который называется find_reply (body)

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

Я нахожу, когда использовать RPSEC против огурца сбивает с толку.

Спасибо

Answer 1

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

Я настоятельно советую вам взглянуть на огуречный рейлкаст с railscasts.com . Кроме того, убедитесь, что вы используете webrat и, возможно, что-то для автоматической загрузки ваших спецификаций, например watchr (что мне больше нравится).

Answer 2

Я бы посоветовал вам никогда не использовать огурец, если вы не работаете в качестве бизнес-аналитика. Это делает вашу жизнь намного проще: все ваши тесты будут в Rspec.

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

Answer 3

Если бы у меня еще не было учетной записи переполнения стека, я бы сделал один ПРОСТО, чтобы написать этот пост.Я призываю перечитать ответ @Jack Kinsella

Я попал в BDD около 3 месяцев назад, влюбился в него и быстро начал использовать CucumberЗа все.Я включил его в каждый проект, несмотря ни на что

Недавно мне пришлось выучить еще один язык, и первым моим шагом было настроить среду тестирования.Я наткнулся на эти 3 статьи:

• http://robots.thoughtbot.com/post/25650434584/writing-better-cucumber-scenarios-or-why-were
• http://robots.thoughtbot.com/post/25653308407/describe-the-users-perspective-ddd-acceptance
• http://37signals.com/svn/posts/3159-testing-like-the-tsa

Честно говоря, их содержаниене так ли важно;важно то, что они намекают на общую идею.Я начал подозревать, что я все время неправильно использовал огурец, и пошел искать ответы.Этим утром я нашел ваш ТАК вопрос, и в блоге @Jack Kinsella

---

@ Джек выходит прямо и говорит, что идея I считает, что эти статьи ориентировочно кружили.Он также дает мне язык 1028 *, который я искал.Теперь я считаю, что его статья является последним словом по этому вопросу:)

По его словам, то, для чего мы фактически использовали Cucumber, - это "интеграционное тестирование".Я никогда не понимал, что это значит, прежде чем

Модульное тестирование :
Как внутренний код работает. Math.Add (1,1) должно быть 2 , но пользователю сайта все равно.Просто дайте мне веб-страницу!
-> Используйте RSpec или эквивалентный

Интеграционное тестирование :
Как разные ветви кода работают вместе для создания сайта. Я ввожу свое имя и нажимаю кнопку «Войти», и его следует перейти на домашнюю страницу
-> ТАКЖЕ использовать RSpec!
(Внутри RSpec добавьте все, что вам нужно для обработки нескольких технологий -Touch-eachother. Для примера кода для web-браузера: Capybara, Watir и т. д.)

Приемочное тестирование :
Многим из нас это не нужно.Кто-то подписал с вами контракт, сказав «Я напишу:« Я могу добавить подстраницы на свой микросайт ».в текстовом файле ".Вы пишете мне код, который заставляет его становиться зеленым
-> Использовать огурец.Только если вам нужно сделать этот вид тестирования.Что вы почти наверняка не знаете

Какое элегантное решение.Нет 2-й тестовой среды.Нет шагов, каталог и рой дополнительных файлов!

У меня был момент "Но мне нравится, как Cucumber отделяет английский от кода".Обычный BDD делает это тоже. "rspec --format nested" или Результаты теста с жасмином

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

Почему бы не признать, что вы не проводите приемочное тестирование и вам оно не нужно в ваших проектах?Поменяйте огурец на чистые интеграционные тесты с использованием Capybara, и вы будете удивлены, насколько продуктивнее вы можете быть

Answer 4

Чтобы завершить ответ SpyrosP, есть замечательное сообщение от Сары Мей, в котором описывается сценарий, в котором вы используете Rspec и Cucumber. Это называется «развитие, управляемое поведением», и вы можете найти здесь .

Answer 5

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

Answer 6

Определенно используйте оба. Используйте cucumber для тестов пользовательского опыта (представления), используйте rspec для тестирования внутренних компонентов (моделей и т. Д.). Вы можете написать тесты rspec контроллера, но я думаю, что они не нужны (попробуйте перенести логику на модели). Какой бы ни была ваша система, я настоятельно советую вам использовать Cucumber, потому что сценарии позволят вам и вашим заинтересованным сторонам знать функции вашей системы в четкой письменной форме. У вас также будет готовая документация, и вы всегда будете знать, где вы находитесь и куда направляетесь. Вы также будете связывать сценарии с проблемами поддержки в будущем. Обдумайте их, кстати, не используйте переменные в сценариях, они должны быть понятными. И если вы хотите, чтобы они работали быстро как rspecs, используйте poltergeist (phantomjs).

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

Answer 7

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

Со временем вы обнаружите, что две большие потребности в тестировании:

1. Мой код все еще работает?
2. Могут ли мои пользователи выполнять уже реализованные действия?

Как разработчик, я склонен думать, что (1) предназначен для каждого отдельного изменения кода и (2), когда я заканчиваю функцию и / или выполняю развертывание.

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

Действительно, оно должно быть настолько общим, что если что-то сломается в (2), вам нужно провести серьезное исследование (одна строка отсутствует в ваших таблицах), в то время как сбой в (1) долженУкажите точный класс с проблемой.

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