Мой ах-ха! моменты о тестировании в 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 удовлетворяют различные потребности.