Ruby on Rails c нуля!

Практикуйте BDD, не будьте похожи на подавляющее большинство PHP программистов

Почему это?!

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

Ранее я только игрался со спецификациями BDD и использовать их в реальной работе не желал. Я изучил поверхностно работу с RSpec просто потому, что «Rspec необходимо знать», а это убеждения возникло у меня из-за частого упоминания RSpec в вакансиях на различных сайтах — агрегаторах вакансий Ruby/Rails программистов. На практике, до недавнего времени я избегал использования RSpec и мне казалось, что очень ловкое шимпанзе, которое успешно избегает всех этих заморочек со спецификациями. Мне казалось, что работая в одиночку можно спокойно обойтись без BDD, и что BDD только забирает время, которое можно потратить на написание кода самого приложения, а не бесполезных с функциональной точки зрения спецификаций. Чуть позже я нашел работу Rails программиста в одной компании, где спецификации также не пишут, а работа по тестирования взгромождена на широкие плечи титанов — тестировщиков. Здесь мне тоже удалось успешно избежать необходимости писать спецификации.

Когда же я начал работать над Quasar CMS то уже было некоторое чувство внутри, что я делаю что-то не так, что нужно все хорошо продумать, но привычка делать, а потом думать привела к тому, что спецификациями покрыто не более 2% кода Quasar CMS и потому я решил заняться написанием спеков ко всему коду, что будет готов на момент 31 мая — так я решил отпраздновать свой день рождения. Это не совсем правильно покрывать спеками уже написанный код, но это лучше, чем когда их совсем нет.

Помимо Quasar CMS я начал еще один свой сверхсекретный мега стартап, который должен сделать меня миллиардером, ну или хотя бы мультимиллионером, а в худшем случае, я просто еще раз повторю имена методов в Rails и, возможно, познакомлюсь с парочкой новых симпатичных Gem’ов. Этот новый супер стартап я начал как раз со спецификаций.

Честно сказать писать спецификации трудно. Трудно не потому, что спецификации — это что-то сложное, а потому, что необходимо много думать, по 7 раз все отмерять и только по разу все отрезать. Кроме того, поскольку опыта в написании BDD спецификаций у меня крайне мало, возникает множество моментов, когда необходимо заглянуть в документацию, StackOverflow или пробежаться по блогам из закладок с метками «RSpec, BDD, …». Разумеется такие упражнения в google-fu приносят свои плоды и откладывают в мозг крупицы знания и понимания сути BDD и его инструментария. Ссылаясь на свой гипертрофированный коэффициент лени и темпы с которыми я осваиваю BDD могу сказать, что на то, чтобы освоить BDD практики и инструментарий в объеме достаточном для автономной работы, то есть без использования Goggle каждые 5 минут, необходимо потратить времени ок. месяца.

О чем это я? Ах да, BDD — это сложно, но это сложно должно превратиться в легко через 1-2 месяца вашего изучения предмета. BDD — это практики, которые действительно необходимы. Поверьте мне как примату, который долго сопротивлялся необходимости использования BDD в работе.

P.S. У PHP разработчиков действительно туго с тестами и спецификациями. В подтверждение тому можете поискать на Хабре соотв. опрос о том, кто использует BDD/TDD.

В этой статье мы рассмотрим:

1. Установку Git 
2. Установку RVM - Ruby Version Manager для возможности работы с несколькими версиями Ruby, а также наборами библиотек Ruby - Gem’ами.
3. Установку собственно Ruby: Ruby 1.8.7 и Ruby 1.9.3
4.  Установку SQLite, MySQL, PostgreSQL
5. Установку фреймворка Ruby on Rails 3.2 и его зависимостей
6. Установку Node.js как среду выполнения JavaScript
7. Создание нового проекта Rails
8. Работу с зависимостями проекта
9. Настройку тестового окружения и написание простых спецификаций и тестов
10. Написание кода приложения по спецификациям
11. Установку Nginx и Unicorn, и запуск приложения Rails на Unicorn и Nginx прокси
12. Работу с удаленным репозиторием
13. Работу с Continuous Integration (CI) сервером - Travis

Read the rest of this entry »

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

Для решения этой проблемы было предложено решение, которое называется Spork. Spork является DRb сервисом (сервером), суть которого заключается в том, что он держит приложение постоянно загруженным, так что вам не нужно его запускать каждый раз вместе с запуском тестов.

В данной статье мы рассмотрим работу Spork совместно с RSpec для Rails 3.2. Мы будем использовать RSpec потому, что он имеет встроенную поддержку DRb сервисов и является одним из самых популярных решений для тестирования и написания спецификаций.
Read the rest of this entry »

UPD: Добавлен параграф об around() хуке.

Доброго времени суток ув. читатель RubyDev’а!
В данный момент автор RubyDev, то есть я, очень похож на белку в колесе ибо он занимается устройством на работу. К сожалению или к великому счастью обязательным условием является умение работать с RSpec, которым автор владеет в совершенстве плохо, по сему, решил я бросить все ресурсы на то, чтобы изучить сие твоение Девида Челимски.

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

Ибо время — деньги, а платить мне никто за это старание не будет, буду совсем краток.
Read the rest of this entry »

Требования:

Ruby >= 1.8.6
Rubygems >= 1.3.7

Установка RSpec

Для установки RSpec воспользуйтесь следующей консольной командой:

$ gem install rspec

Благодаря этой команде Rubygems установит следующие gem’ы:

rspec
rspec-core
rspec-expectations
rspec-mocks

Gem rspec-core устанавливает консольную команду rspec. Запустите команду rspec с параметром —help чтобы увидеть доступные опции:

$ rspec —help

С места в карьер!

Напишем простой пример, который описывает желаемое поведение программы:

# bowling_spec.rb

describe Bowling do
  describe "#score" do
    it "returns 0 for all gutter game" do
      bowling = Bowling.new
      20.times { bowling.hit(0) }
      bowling.score.should == 0
    end
  end
end

Read the rest of this entry »

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

RSpec один из моих любимых инструментов. Я без преувеличений влюбился в эту фантастическую библиотеку для BDD тестирования, особенно во вторую версию. Используя RSpec, я понял, что эта библиотека учит меня тому, как правильно писать тесты. Изучая RSpec DSL , его синтаксис и структуру примеров spec’ов (далее по тексту просто спеки) вы фактически изучаете лучшую методику написания тестов. RSpec, несмотря на множество встроенных условий проверки, содержит еще и DSL для объявления ваших собственных проверок, которые заточены по ваши личные, специфичные нужды. Возможно все это звучит несколько запутывающе, однако все достаточно просто, так просто, что в это сложно поверить, пока сам не попробуешь.

Основы

В RSpec проверки (matchers) ничто иное как методы доступные в контексте примера. Вы используете их, чтобы убедиться в том, что результат работы тестируемого кода соответствует переданому ожиданию (проверке, условию при котором тест возвратит значение true, что свидетельствует, что данная проверка пройдена успешно и код работает так, как мы того ожидали). Существует множество проверок, которые уже входят в состав RSpec. В примере ниже показано использование одной из таких проверок respond_to:

describe String do
  it { should respond_to(:gsub) }
end

Read the rest of this entry »