Мой ах-ха! моменты о тестировании в Ruby и Rails наступили, когда я действительно сел и прочитал исчерпывающие ресурсы по этой теме, книги по Rspec и Cucumber . Я поделился вашим первоначальным презрением к огурцу, но потом понял, что смотрю на картинку с совершенно неправильной точки зрения.
По сути, Cucumber - это BDD (разработка, основанная на поведении) - вы используете Cucumber для планирования своих функций, над которыми вы будете работать дальше. Хм, затем вы хотите, чтобы пользователи могли продвигать посты на форуме или что-то в этом роде (чтобы украсть пример;)) Итак, вы пишете что-то простое.
Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.
Обратите внимание, что там нет ссылок на что-либо связанное с кодом. Это входит в ваши шаги. Когда вы реорганизуете свой код, вам, возможно, придется изменить определения шагов, но поведение (ваша функция) никогда не будет нуждаться в изменении.
Теперь каждый раз, когда вы запускаете свою функцию Cucumber, вы будете в значительной степени получать инструкции о том, как протестировать эту функцию с помощью TDD (разработка через тестирование). Это делается на более низком уровне с использованием RSpec.
Первый запуск - мое определение первого шага не определено. Скопируйте блок, чтобы определить его, скажем, user_steps.rb или даже session_steps.rb, поскольку он относится к пользователям и их сеансам. Теперь, как вы определяете, что пользователь вошел в систему? Вы можете принять их через процесс входа в систему.
Given /^I am logged in$/ do
visit login_path
fill_in :name, :with => 'Joe'
fill_in :password, :with => 'Password'
click_button 'submit'
end
Должно быть все счастливы. Второй шаг.
Given /^I can see the post "(.+)"$/ do |name|
visit post_path(Post.find_by_name(name))
end
Опять довольно просто. Обратите внимание, что если мы полностью переделали наш процесс входа в систему или то, как наши сообщения определены и показаны, нам не нужно менять поведение. Третий шаг.
When /^I vote the post up$/ do
pending
end
Здесь вы начинаете говорить о новой функциональности, но пока не знаете, как она будет работать. Как вы голосуете за пост? Вы можете щелкнуть изображение +1 или чего-то еще, что делает запись ajax контроллеру, который возвращает JSON, или что-то подобное. Так что теперь вы можете перейти к чистому тестированию Rspec.
- Проверьте свой вид, чтобы убедиться, что изображение +1 отображается,
- Проверьте свой контроллер на правильность работы, когда он получает заданный ajax-запрос правильного формата (как счастливый, так и несчастный путь - что, если получен недопустимый идентификатор сообщения? Что произойдет, если пользователь израсходовал 25 своих голосов за день? Правильно ли увеличивается число голосов?)
- Проверьте ваш javascript на правильность ответа, когда ему предоставлен BLOB-объект JSON в правильном формате (обновляет ли он изображение +1, чтобы показать, что он был использован? )
Все это не влияет на поведение - но когда вы закончите работу с тестированием более низкого уровня, заполнить определение шага, как проголосовать за публикацию, будет тривиально. Это может быть так же просто, как click_link '+1'. А остальные шаги - это результаты тестирования, которые опять же должны быть простыми. И когда вы закончите, то вы знаете, что ваша функция завершена и завершена. Если необходимое поведение изменяется, вы можете настроить свою функцию, иначе вы можете настроить свой код реализации в полной безопасности.
Я надеюсь это имеет смысл. Все это было не в моей голове, но я думаю, что это демонстрирует разницу между BDD и TDD, и почему Cucumber и RSpec удовлетворяют различные потребности.
Тестирование, на мой взгляд, это искусство. При использовании TDD (с использованием RSpec или любой другой среды) изначально создается ощущение, что вы «тратите свое время». Это понятно, потому что вы не пишете никакого производственного кода.
Однако вы начинаете видеть преимущества TDD, когда вам нужно улучшить свою кодовую базу, при этом гарантируя, что все остальное все еще работает. TDD поможет вам обнаружить ошибки регрессии как можно раньше. Выполнение этого сэкономило мне дни работы, потому что я сфокусировал тесты, которые указали на мои ошибки.
Кроме того, наличие тестов может быть полезным для проверки кода, поскольку ваш рецензент может видеть, какие сценарии вы тестируете и как ваш код предназначен для использования.
Как только вы попадаете в топ TDD, делать что-то еще - это неправильно.
источник
Я полагаю, что ты прямо на огуречном фронте. Написание всех этих шагов - большая проблема, и преимущества не оправдывают боль. Я много писал о шести недостатках использования огурца здесь: зачем беспокоиться о тестировании огурца?
Модульные тесты и регулярные интеграционные тесты, выполняемые либо с помощью Rspec, либо Test :: Unit, имеют большой смысл, но, к счастью, они гораздо быстрее пишутся, чем тесты Cucumber. Например, вы можете использовать чистый Ruby вместо того, чтобы бороться с многословным и неловким синтаксисом Gherkin.
источник
Во что я лично верю, так это
RSpec testing is a definite must. Скажем, например, что вы хотите написать новую функцию, которая также имеет ссылку на какую-то другую функцию, и на эту функцию может ссылаться другой модуль или методы. Итак, как вы можете убедиться, что то, что вы пишете, не нарушает любую другую часть приложения?Предположим, что у вас большое приложение и что вы написали что-то тривиальное по сравнению с общим приложением, будете ли вы повторно тестировать все приложение, нажимая каждую ссылку в приложении, чтобы убедиться, что оно работает каждый раз, когда вы меняете одну строку кода?
Тем не менее, я считаю, что тестирование на огурец не является обязательным. Я думаю, что интеграционное тестирование с использованием самого RSpec имеет больше смысла до тех пор, пока ваш клиент не проверит тесты. Который по моему опыту редкий. Если ваша команда целиком состоит из разработчиков, то я думаю, что вам лучше заменить этапы Cucumber для тестирования функций RSpec. И я думаю, что после RSpec 3 DSL тесты в значительной степени читабельны.
Пример:
Определение шага огурца:
Функциональный тест RSpec:
Я думаю, что вместо того, чтобы иметь функции Cucumber, функции RSpec делают то же самое без лишней головной боли написания других определений шагов.
Кроме этого это также чисто ваши собственные предпочтения.
Надеюсь, это поможет вам немного понять.
источник
На мой взгляд, первое, что нужно дифференцировать между практикой и конкретными рамками. Огурец его не BDD, RSpec его не TDD.
Если вы хотите протестировать свою систему RSpec, это хороший инструмент, вы можете сделать TDD или BDD с RSpec, фактически TDD и BDD - это одно и то же. Кто-то говорит: «BDD - это TDD, сделанный правильно», и я полностью согласен с этим, BDD в первую очередь касается тестирования функций / поведения, а не методов / классов тестирования. На самом деле TDD, который Кент Бек описывает, об особенностях, но BDD помогает многим людям понять это ключевое отличие и его большой вклад от Дана Норта в сообщество разработчиков.
Используйте Cucumber, если считаете, что вам нужен лучший инструмент для общения с деловыми людьми, например, если Cucumber позволяет, чтобы ваши деловые люди или владелец продукта помогали команде в написании или пересмотре сценариев. Другим людям нравится cucumber, потому что эти сценарии - действительно хорошая документация системы, если вы чувствуете, что вам нужна документация такого типа, попробуйте cucumber.
В итоге:
Конечно, с двумя последними связаны высокие издержки, вам нужно оценить, действительно ли вам это нужно и стоит ли усилий, это, конечно, полностью зависит от вашего проекта и вашей среды, а также от вашего решения.
Но всегда помните, что RSpec и Cucumber - это всего лишь инструменты, а инструменты решают конкретные проблемы, какую проблему вы хотите решить? Задайте себе этот вопрос, и вы, вероятно, в лучшем положении, чтобы выбрать правильный инструмент. Быть лучшим программистом - это принимать решения, а не использовать X или Y framework / tool / library / technology.
источник