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 »

Я отношусь к тойкасте людей, что не воспринимают интеграционные тесты. Программа не может оценить внешний вид приложения так, как то может сделать человек. По этой причине я предпочитаю сам смотреть на то, как выглядит приложение. Для того, чтобы это изучение приложения было максимально приближена к реальности — необходимо заполнять базу тестовыми данными, кроме того, тестовые данные необходимы для тестирования производительности приложения на «реальных» данных. В Rails имеется встроенный механизм seed-ирования базы данных, однако он мне не очень нравится и в этой статье я рассказывать о нем не буду. Вместо встроенного функционала я предпочитаю использовать seed-fu — отличное решение поставляемое в виде совсем обыкновенного gem’а, которое делает заполнение БД тестовыми данными более удобным.
Read the rest of this entry »

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

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

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

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

Rails 3 снабжен очень мощной системой уведомлений о происходящем внутри приложения. Давайте на примере простого приложения рассмотрим то, что есть уведомления и как с ними работать.

Мною было создано простое приложение с одной моделью и контроллером:

$ rails g scaffold User name:string email:string login:string

Именно на примере такого простого приложения мы и рассмотрим уведомления. Давайте запустим наше приложение:

После запуска приложения мы увидим в консоли следущее:

$ rails s
=> Booting WEBrick
=> Rails 3.0.7 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-05-22 11:48:04] INFO  WEBrick 1.3.1
[2011-05-22 11:48:04] INFO  ruby 1.9.2 (2010-08-18) [i686-linux]
[2011-05-22 11:48:04] INFO  WEBrick::HTTPServer#start: pid=3670 port=3000

Это означает, что приложение загружено в память и что сервер приложения был запущен, однако само приложение ничего не выполняет. При переходе на http://localhost:3000/ мы также ничего нового в консоли не убидим, поскольку мы перешли на статическую страницу приветствия, которая нам была отдана нашим сервером, по умолчанию, а не приложением. Однако, когда мы перейдем по адресу http://localhost:3000/users/ то есть приложение выполнит экшен index в контроллере UsersController, то в консоли мы увидим следущее:

Started GET «/users» for 127.0.0.1 at 2011-05-22 11:52:59 +0300
Processing by UsersController#index as HTML
User Load (0.8ms)  SELECT «users».* FROM «users»
Rendered users/index.html.erb within layouts/application (4.4ms)
Completed 200 OK in 158ms (Views: 11.4ms | ActiveRecord: 0.8ms)

Это называется записью логфайла, которая создается на основе уведомлений (Rails Notifications). Если интересно, то файлы логов можно найти в ../log/ в нашем случае это development.log по названию окружения в котором мы работаем. Файл логов содержит абсолютно то же, что было напечатано в консоли.

Если мы перейдем по ссылке создания нового пользователя, то в лог-файле и в консоли появится еще одно сообщение логера:

Started GET «/users/new» for 127.0.0.1 at 2011-05-22 14:20:03 +0300
Processing by UsersController#new as HTML
Rendered users/_form.html.erb (87.8ms)
Rendered users/new.html.erb within layouts/application (107.4ms)
Completed 200 OK in 431ms (Views: 153.4ms | ActiveRecord: 0.0ms)
Read the rest of this entry »

Rails 3 снабжен очень мощной системой уведомлений о происходящем внутри приложения на основе которой строятся логи приложения. Не смотря на то, что уведомления первичны, мы начнем с лог файлов.

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

Все логи хранятся в папке ../log/ ваше приложения и записываются в файлы с именем окружения (development, test и production) и расширением *.log. Зачем логи нужны? По логам можно определить что делало приложение в определенный момент времени или увидить ошибки и попытки взлома приложения.

Rails, по умолчанию использует из Ruby StdLib. Давайте сначала расмотрим работу конкретно с этим логером вне контекста Rails.
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 »