def self.bps_global_navi
doc = Nokogiri::HTML(open(BPS_SITE_URL)) # スクレイピング先のURLを指定
navi_list = Array.new
doc.css(BPS_TARGET_CSS).each do |link| #
navi_list << link.content
end
return navi_list
end
end

こんにちは、hachi8833です。

Rails 4.1.1環境でなぜかPoltergeistでスクリーンショットを保存できない問題が解決したら記事にしようと思っていたのですが、間に合わなかったので今回はConfiguring database_cleaner with Rails, RSpec, Capybara and Seleniumという記事を翻訳してみました。
なお、この記事の内容は、弊社で行った「Crafting Rails 4 Applications読み会:第8回資料」と密接に関連します(スライド47 – 53ページあたり)。

解説

RSpecの1つ1つのテスト(beforeとafterも含めて1つの単位とします)は本来互いに独立すべきものなので、本来であればどのような順序で実行されても同じ結果にならなければなりません。だからこそRSpecは2.8からテスト実行順序をランダム化(config.order = "random")できるようになったのです。

しかしテストの量が増えてきたり古いRails環境だったりすると、データベースに残ったデータに知らず知らずに依存してしまうテストが増えてきます。その結果、「単体だと正常に実行できるのに全体テストでエラーになるテスト」や逆に「全体テストでは正常なのに単体だとエラーになるテスト」ができてしまいます。

前者は、たとえば同一のファクトリーを異なるテストでcreateしている場合が考えられます。それぞれのテストではファクトリーをcreateするのは正当なことですが、全体テストでは最初にcreateしたファクトリーが残留して、かつそのモデルで重複が禁止されていれば、2度目のcreateでエラーが生じてしまいます。

後者は、先に行われたテストで生成されたファクトリーに後のテストが依存している場合が考えられます。全体テストではとおりますが、単体だとファクトリーが足りずエラーになります。

database_cleanerを導入するのは、このような状態を避けるためでもあります。もっとも大量のテストがある巨大プロジェクトにdatabase_cleanerを追加すると、依存関係によるエラーが続々見つかって修正が大変かもしれませんが。

個人的には、テストはDRYを目指すより、前処理や後処理が多少重複しても独立性を目指すほうがよいように思います。

[翻訳]Rails/RSpec/Capybara/Seleniumでdatabase_cleaner gemを使う

元記事: Configuring database_cleaner with Rails, RSpec, Capybara and Selenium

Railsのコードを書いている人、Rubyでデータベースを扱うコードを書く人、テストを自動化している人なら、database_cleanerというgemを何となく知っていたり使ったりしたことがあることでしょう。これは実際よくできたgemで、さまざまなORM APIを抽象化してデータベースをきれいな白紙の状態に戻してくれます。

私は定期的にRSpec/Capybara/Selenumを使うRailsプロジェクトを新たに立ち上げていますが、そのたびにテストデータベースの一貫性が損なわれてしまうという憂き目に遭っています。せっかくテストデータベースにレコードをいくつか設定しても、Seleniumで駆動されるブラウザベースのテストは、そんなレコードなどどこにもないかのように振る舞います。最後にやっと問題点を解決し、そのたびに前にも同じ問題に遭遇して同じように解決していたことを思い出すのです。三歩歩くと忘れてしまうおのれの鳥頭が情けなくなります。

ぶつかる問題点は毎度同じです。テストはデータベーストランザクションによってラップされているので、実際のテストプロセスの外で実行されるあらゆるコード(つまり、Seleniumで駆動されるブラウザのリクエストに応答するサーバープロセスなど)からは、そのままでは私が作ったデータベースフィクスチャを参照できないのです。

ちょうどこの間ペアプログラミングを行ったときにも同じ問題を解決したので、そのときの作業を忘れないうちにメモします。皆様の髪の毛が抜けてしまわないために役立てば幸いです。

最初の手順、ここがとにかく肝心です。spec/spec_helper.rbを変更します。

config.use_transactional_fixtures = true

上の設定を以下のように変更してください。

config.use_transactional_fixtures = false

rspec-railsは暗黙のうちにデータベーストランザクションをラップしているのですが、これをオフにしておきます。そうしないと以下の設定が無意味になってしまいます。

次にdatabase_cleanerを設定します。私の場合、spec/support/database_cleaner.rbというファイルをそれ用に作成します。内容はだいたい以下のような感じです。

RSpec.configure do |config|

  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each, :js => true) do
    DatabaseCleaner.strategy = :truncation
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

end

解説

順に説明します。

config.before(:suite) do
  DatabaseCleaner.clean_with(:truncation)
end

上の設定は、テストスイート全体が実行される前にテストデータベースを完全に消去します。これにより、中断したテストや下手なテストコードによって生じたゴミを一掃し、テストが思わぬ振る舞いをするのを防ぎます。

config.before(:each) do
  DatabaseCleaner.strategy = :transaction
end

上の設定は、データベース消去のストラテジを”transaction”に設定します。トランザクションは非常に速いので、トランザクションを実行するすべてのテスト(実際のところ、RSpecプロセスで実行されるすべてのテスト)において、この設定を行っておくのがよいでしょう。

config.before(:each, :js => true) do
  DatabaseCleaner.strategy = :truncation
end

上の設定は、「:js => true」フラグが設定された例の前でのみ実行されます。デフォルトでは、Capybaraがテストサーバープロセスを起動してSeleniumバックエンド経由で実際のブラウザを駆動するのはこのようなテストだけです。このようなテストではトランザクションが動作しないので、このコードで設定を上書きしてストラテジを”truncation”に変更しています。

config.before(:each) do
  DatabaseCleaner.start
end

config.after(:each) do
  DatabaseCleaner.clean
end

上の設定は、1つ1つのテストの実行前と実行後にdatabase_cleanerをフックしています。どのようなデータベース消去ストラテジを選択していても、database_cleanerが常に実行されるようにしています。

以上です。
上のコードはRSpec用であり、Cucumberの設定までは考慮していないことにご注意ください。

私が受けたストレスを皆様が避けることができれば幸いです。

追記

Gistで行っているようにすべてのスレッドを同一のActiveRecord接続で共有しないのはどうしてなのかという質問を何人かの方から受けました。いくつか理由を説明します。

• database_cleaner を使用するのは、ORM(オブジェクト/関係マッピング)が中立であることを期待しているからです。database_cleaner はActiveRecord、DataMapper、MongoMapperなどをサポートしていますが、Gistで説明されているソリューションはActiveRecordでしか動作しません。
• Gistのモンキーパッチによる方法は、ActiveRecordが内部での接続共有を変更しない間しか有効ではありません。正直、この方法がすべてのRuby VMとデータベースの組み合わせで動作するのかどうか私には確信がありません(追記: 現行のPostgreアダプタで競合が生じるという報告が2名からあがっています)。すべてのコンテキストで動作する設定オプションがActiveRecordにあれば私もこの方法をもっと使うかもしれません。
• 上で強調したように、これを必要とするテストだけがtruncationにフォールバックするように注意を払いました。:js => trueを使用するテストの量は、私の場合多くはありません(そもそもブラウザを駆動するとどうしても速度が低下してしまいますから使い過ぎないようにしています)ので、私のソリューションで生じるオーバーヘッドについては気にしすぎないようにしています。受け入れテストでブラウザ駆動を全面的に行なうことがあればその点をもう少し気にしたでしょう。
• データベースをtruncateするとテスト時間が大きく増加するのであれば、そのテストで特定のテーブルのサブセットだけをtruncateするように改良することで速度を向上できるでしょう。database_cleaner を採用しているのはそれがやりやすくなるからでもあります。これについては後日記事にするかもしれません。

追記: @donaldballから良い指摘がありました。テストとテストサーバー間のトランザクションを共有すると、production環境での実行と挙動が異なる部分が生じてしまいます。特に、production環境ではafter_commitフックは決して起動されません。

関連する投稿:

1. Rack-Test and Capybara are uneasy bedfellows
2. Announcing NullDB 0.0.1
3. Complex Hash Expectations in RSpec

こんにちは、hachi8833です。小ネタなのでQiitaに書こうかと思いましたが、こちらにしました。

Railsのビューテンプレートで配列の内容を改行brで区切って縦に一覧表示したいとき(普通ならulを使うところですがあえてbrにします)、こんなコードを最初書いてみました。なおビューではhamlを使用しています。

#コントローラ
@my_array = ['太郎', '次郎', '花子']

#ビュー
=@my_array.join('<br/>').html_safe

が、書いてみてすぐ、このコードが脆弱なため使えないことに気付きました。ここで@my_arrayはユーザーが入力した内容をDBから取り出したものなので、ユーザー入力に悪意のあるタグが含まれていたらXSS脆弱性が発現してアウトです。ビューでユーザー入力にhtml_safeをかけるのは禁じ手です。

何かスマートな方法はないかと探してみたところ、Rails 3.1からsafe_joinというそれ用のヘルパーメソッドが追加されていました。

# File actionpack/lib/action_view/helpers/output_safety_helper.rb, line 31
      def safe_join(array, sep=$,)
        sep = ERB::Util.html_escape(sep)

        array.map { |i| ERB::Util.html_escape(i) }.join(sep).html_safe
      end

今回惜しくもRailsのバージョンが3.0だったので、上のコードをヘルパーに追加しました。また、そのままでは区切り文字までサニタイズされてしまうので、sep = ERB::Util.html_escape(sep)は削除しました。
お互いセキュリティには気を付けましょう。

こんにちは、hachi8833です。最近ますます好きになってきたTurnipを使いやすくするため、たいていの受け入れテストで使い回せるTurnipステップをテンプレとしてまとめてみました。ある程度ですがCapybaraのカンニングペーパーにもなります。

## -*- encoding: utf-8 -*- 
## 一般的に利用できるTurnipステップ

## テスト用ステップ

	#表示テキスト存在確認
step %(:textと表示されている) do |text|
  expect(page).to have_content(text)
end

	#表示テキスト不在確認
step %(:textと表示されていない) do |text|
  expect(page).not_to have_content(text)
end

## 操作用ステップ

	#ページ移動
step %(:pageページにアクセスする) do |page|
  visit "http://localhost/#{page}"
end

	#リンクをクリック (textはリンク文字列かid)
	#同じ名前のリンクが複数ある場合には文字列は指定できない
step %(:textリンクをクリックする) do |text|
  click_link text
end

	#同じ名前のリンクが複数ある場合に順序も指定
step %(:n番目の:textリンクをクリックする) do |n, text|
  n = n.to_i - 1
  all(:link_or_button, text)[n].click
end

	#ボタンをクリック (textはボタン文字列かid)
	#同じ名前のボタンが複数ある場合には文字列は指定できない
step %(:textボタンをクリックする) do |text|
  click_button text
end

	# フィールドに文字列を入力する |fieldはモデル[属性]の形式
step %(:fieldに:valueを設定する) do |field, value|
  fill_in field, with: value
end

	# ドロップダウンボックスを選択 (textはボタン文字列かid)
	#同じ名前の項目が複数ある場合には文字列は指定できない
step %(:choiceを選択する) do |choice|
  choose choice
end

	# チェックボックスを選択  (choiceは文字列かid)
	# 同じ名前の項目が複数ある場合には文字列は指定できない
step %(:choiceをチェックする) do |choice|
  check choice
end

	# チェックボックスを選択解除  (choiceは文字列かid)
	# 同じ名前の項目が複数ある場合には文字列は指定できない
step %(:choiceのチェックを外す) do |choice|
  uncheck choice
end

## デバッグ用

	# pryを呼ぶ (pry, pry-rails, pry-doc がインストールされていること)
step %(pryを呼び出す) do
  binding.pry
  puts ''
end

	# その時点の静的なwebページを表示する
step %(表示する) do
  save_and_open_page
end

	# ペンディング用
step %(:reasonという理由でペンディング) do |reason|
  pending reason
end

こういうのをこしらえておけば、Turnipのfeatureファイルも以下のような感じでざくざく書けます。

    前提 "[参加者一覧]"リンクをクリックする
    ならば "参加者一覧"と表示されている
    かつ "[参加者編集]"リンクをクリックする
    かつ "[追加]"リンクをクリックする
    ならば "1件追加"と表示されている
    かつ "sankasha[name]"に"参加者001"を設定する
    かつ "sankasha[yomi]"に"さんかしゃよみ"を設定する
    かつ "sankasha[zip_code]"に"239-0803"を設定する
    かつ "sankasha[address]"に"住所1"を設定する
    かつ "sankasha[sub_address]"に"住所2"を設定する
    かつ "sankasha[tel]"に"03-671-2500"を設定する
    かつ "sankasha[fax]"に"03-671-2501"を設定する
    かつ "sankasha[eigyou]"に"営業太郎"を設定する
    かつ "sankasha[email]"に"eigyou@eigyou.com"を設定する
    かつ "追加"ボタンをクリックする
    ならば "参加者001を作成しました"と表示されている

認証やfactoryの準備などはもちろん別途行う必要がありますが、画面ナビゲーションレベルについては大抵間に合うのではないかと思います。皆様も適宜これをカスタマイズしてお使いいただければと思います。Githubにも置きましたので、今後はこちらを更新します。

ここまで落とし込めれば、お客さんにfeatureファイルを書いてもらうことも夢ではないかもしれません(現実にはなかなかないでしょうけれど)。

こんにちは、hachi8833です。

なかなかRSpecをうまく書けずに悩んでましたが、morimorihogeさんに教えてもらって、RSpecのモックとスタブの使い分け方が少し見えてきたのでメモします。

スタブの目的

そもそもスタブを使用する目的は、本当にテストしたいところだけをテストできるように、本筋に関係ない部分(バリデーションなど)をとにかく動くようにする、動かしたい場所まで辿り着くことです。例えて言うなら、ペンキを塗ったりエアブラシを使うときに、塗料が付いて欲しくない部分に貼るマスキングテープをイメージするとよいでしょう。テストしたい箇所以外はスタブで塞いでしまうわけです(以下の4行目)。

#vtypes_controller_spec
describe "POST create" do
  it "create_from_text が呼ばれ，client_vtypes_path を再表示すること" do
    Vtype.stub(:type_string).and_return(10)      # ここがスタブ
    post :create, text:"data_text", vtype:"10"   # テストしたいアクション
    response.should redirect_to(client_vtypes_path(filtered_vtype:"10")) # アクションの結果をテスト
  end
end

上の4行目では、下のモデルにあるtype_stringメソッドを偽って、type_stringが10という値を返したということにしてくれています。
以下はVtypeモデルです。

# Vtypeモデル
# name:: 種別 - 日本語 (string)，null 不可
# sort_order:: 並び順カラム (integer)，null 不可
class Vtype < ActiveRecord::Base
  def self.type_string(num)
    return self.find_by_sort_order(num).name
  end
end

なお以下はコントローラのcreateアクションの抜粋です。

#vtypes コントローラ
def create
  @vtype  = params[:filtered_vtype]
  if @vtype.save
    flash[:notice] = "#{@v.name}を作成しました"
    redirect_to client_vtypes_path(filtered_vtype: @vtype) and return
  else
    @vtype = params[:filtered_vtype]
    render action:'new'
  end
end

スタブのメリットは、オブジェクトやメソッドのふりをするだけなので、データを用意するフィクスチャーやファクトリーよりも高速である点です。また、本筋に関係ない部分が未実装であっても、スタブを使用できます。完全にシステムをだますことができるわけです。

このことからわかるように、「スタブで塞いだ箇所はテストされたことになりません」。スタブで塞いだ部分は、結合テストなど他のどこかの箇所で最終的にテストされていなければなりません。極端に言えば、テストがスタブだけですべて固められてしまっていればそもそもテストの意味がありません。

従って、スタブを多用し過ぎると、その部分を他でテストし忘れていた場合、「テストは通るのに本番でエラーになる」ということになりかねません。

Railsの場合、スタブを使う場所は基本的には単体テスト、主にコントローラになると思います。コントローラのテストは「不要である」と言われることが多く、初心者はコントローラのテストを作るべきかどうか迷いがちですが、結合テストや受け入れテスト(features、requests、acceptanceなど)が別途行われるのであれば、コントローラではアクションが動作することだけ確認すればよいと思います。実際、scaffoldで生成されるコントローラspecはアクションが動くことを確認しているだけです。

モックの目的

モックはスタブと似た面がありますが、モックはそれ自体がテストになり得る点がスタブとは決定的に異なります。これは、テストする対象のオブジェクトが実装されてないとモックは使えないからです。テスト対象オブジェクトがなくても動くスタブとはその点が違います。
実は、モックはその内部でスタブをこっそり使っています。モックを実行すると、最初にスタブを内部で作成してから動かし、次に実際のオブジェクトに同じデータを与えて動かし、両者の結果が同じかどうかを比較します。結果が合えばパス、違えば失敗となるわけです。

describe "POST create" do
  before :each do
    mock_budget.should_receive(:budget_main).and_return(mock_budget_main)
    mock_budget.should_receive(:budget_owner).and_return(mock_budget_owner)
    mock_budget.should_receive(:budget_unit).and_return(mock_budget_unit)
  end

  it "redirects to new_contract_path when creation of contract succeeds" do
    mock_budget.should_receive(:save).and_return(true)
    post :create, budget:{these: :params}
    response.should redirect_to(new_contract_path(budget_id:mock_budget.id))
  end
end

従って、モックはスタブと同様のマスキングテープ的な使い方もできますし、それ自体をテストコードにすることもできます。上のコードの3, 4, 5行目はbeforeの中でスタブ的に使っていますし、9行目ではテストとして書かれています。

おまけ

なお、モックとスタブはてっきりRSpec固有の機能かと思ったら、元々テスティング一般で使用される概念だったんですね。今回参考にした「Ruby on Railsでのモックとスタブの作成」にさらっと『もしかすると私達は、これらの概念の表現としては不適切な言葉を選んでしまったのかもしれません。しかし今や、これらの言葉を使わざるをえません。』と書かれていることからわかるように、モックとスタブという言葉は割りと混乱を呼んでいます。モックとスタブについてこれまでいろんな説明がなされていますが、どれもどうもしっくりこなかったので、自分にとってのまとめとしてこの記事を書きました。

熱いワールドカップが終わって平和な夜に戻ったshibuso です。Rails ユーザの皆さんは色々rails genarate コマンドを利用しているかと思いますが、この前調べていたら「こんなにあったのか！」となったので、今回Rails のgenerator を大まかに紹介してみます。Rails のバージョンは4.0.1 です。

実行結果をまとめてみました

結構数があるので先に目次を作っておきます。順番は重要そうなものだったり気の向くままだったりしていますので、大して意味はありません。

• scaffold
• scaffold_controller
• controller
• resource
• model
• migration
• assets
• helper
• generator
• integration_test
• jbuilder
• mailer
• task

rails generate scaffold

これはもう使ったことがない人はいないレベルでメジャーじゃないでしょうか。モデル名を指定することによりRails のMVC モデルに則った各種ファイルを生成してくれます。article と入力して実行した結果は以下のとおりです（これより下、全て名前をarticle で実行しています）

$ rails g scaffold article
      invoke  active_record
      create    db/migrate/20140716040221_create_articles.rb
      create    app/models/article.rb
      invoke    test_unit
      create      test/models/article_test.rb
      create      test/fixtures/articles.yml
      invoke  resource_route
       route    resources :articles
      invoke  scaffold_controller
      create    app/controllers/articles_controller.rb
      invoke    erb
      create      app/views/articles
      create      app/views/articles/index.html.erb
      create      app/views/articles/edit.html.erb
      create      app/views/articles/show.html.erb
      create      app/views/articles/new.html.erb
      create      app/views/articles/_form.html.erb
      invoke    test_unit
      create      test/controllers/articles_controller_test.rb
      invoke    helper
      create      app/helpers/articles_helper.rb
      invoke      test_unit
      create        test/helpers/articles_helper_test.rb
      invoke    jbuilder
      create      app/views/articles/index.json.jbuilder
      create      app/views/articles/show.json.jbuilder
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/articles.js.coffee
      invoke    scss
      create      app/assets/stylesheets/articles.css.scss
      invoke  scss
      create    app/assets/stylesheets/scaffolds.css.scss

（※同プロジェクトで作っては消してを繰り返してたので、実行環境によって新規作成だったり既にあるのを使ったり、多少結果の見え方に違いが出ます）

rails generate scaffold_controller

scaffold と比べるとあまり使われていないのではないかと勝手に思っているのがこのscaffold_controller です。scaffold の実行で出力されるコントローラとビューと、それらに関わる部分を切り出した感じで生成します。モデルやアセットは作られません。モデルだけ先に作った場合、地味に便利です。

$ rails g scaffold_controller article
      create  app/controllers/articles_controller.rb
      invoke  erb
      create    app/views/articles
      create    app/views/articles/index.html.erb
      create    app/views/articles/edit.html.erb
      create    app/views/articles/show.html.erb
      create    app/views/articles/new.html.erb
      create    app/views/articles/_form.html.erb
      invoke  test_unit
      create    test/controllers/articles_controller_test.rb
      invoke  helper
      create    app/helpers/articles_helper.rb
      invoke    test_unit
      create      test/helpers/articles_helper_test.rb
      invoke  jbuilder
      create    app/views/articles/index.json.jbuilder
      create    app/views/articles/show.json.jbuilder

rails generate controller

コントローラを生成します。scaffold_controller との違いはRESTful な設計を特に考えない土台を作っているというところです。ビューに関してはディレクトリは作成されますが、中に誰もいませんよ中は空です。こちらはアセットを作っています。また入力した単語は複数形にならずそのまま使われます。

$ rails g controller article
      create  app/controllers/article_controller.rb
      invoke  erb
      create    app/views/article
      invoke  test_unit
      create    test/controllers/article_controller_test.rb
      invoke  helper
      create    app/helpers/article_helper.rb
      invoke    test_unit
      create      test/helpers/article_helper_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/article.js.coffee
      invoke    scss
      create      app/assets/stylesheets/article.css.scss

rails generate resource

恥ずかしながらこの記事をまとめるまで、このコマンドは使ったことがありませんでした。scaffold と同じようにMVC モデルに沿って生成しますが、こちらはRESTful を意識していないようです。そのためコントローラの中身もビューも空です。

$ rails g resource article
      invoke  active_record
      create    db/migrate/20140716080820_create_articles.rb
      create    app/models/article.rb
      invoke    test_unit
      create      test/models/article_test.rb
      create      test/fixtures/articles.yml
      invoke  controller
      create    app/controllers/articles_controller.rb
      invoke    erb
      create      app/views/articles
      invoke    test_unit
      create      test/controllers/articles_controller_test.rb
      invoke    helper
      create      app/helpers/articles_helper.rb
      invoke      test_unit
      create        test/helpers/articles_helper_test.rb
      invoke    assets
      invoke      coffee
      create        app/assets/javascripts/articles.js.coffee
      invoke      scss
      create        app/assets/stylesheets/articles.css.scss
      invoke  resource_route
       route    resources :articles

rails generate model

モデルの生成と、テーブルをcreate するマイグレーションを生成します。

$ rails g model article
      invoke  active_record
      create    db/migrate/20140716040948_create_articles.rb
      create    app/models/article.rb
      invoke    test_unit
      create      test/models/article_test.rb
      create      test/fixtures/articles.yml

rails generate migration

scaffold に負けず劣らず有名ドコロです、使用頻度で考えるとscaffold よりも多いのではないでしょうか。カラムの型変更からテーブルの追加・削除まで、DB に関する各種変更の操作を記述可能なマイグレーションを生成します。

$ rails g migration AddNameToArticles
      invoke  active_record
      create    db/migrate/20140716052116_add_name_to_articles.rb

rails generate assets

アセットを生成します。最初のscaffold のところからそうですが、CoffeeScript とSass を導入しているためcoffee ファイルとscss ファイルが生成された例となっていますが、入っていない場合はそれぞれ普通のjs ファイルとcss ファイルになります。ここでは入力した単語は複数形にならずにそのまま用いられます。

$ rails g assets article
      invoke  coffee
      create    app/assets/javascripts/article.js.coffee
      invoke  scss
      create    app/assets/stylesheets/article.css.scss

rails generate helper

ヘルパーを生成します。合わせてテストも生成します。こちらも複数形にはなりません。

$ rails g helper article
      create  app/helpers/article_helper.rb
      invoke  test_unit
      create    test/helpers/article_helper_test.rb

rails generate generator

generator を generate します…って、これだけではいまいち理解できないですね。generate する時にgenerator を指定することができるみたいで、そのgenerator をまずgenerate するんだそうです。generator がゲシュタルト崩壊を起こしそう…。詳しくはRailsGuides 等を読んでいただけたらと思います。

$ rails g generator article
      create  lib/generators/article
      create  lib/generators/article/article_generator.rb
      create  lib/generators/article/USAGE
      create  lib/generators/article/templates

rails generate integration_test

インテグレーションテスト（総合テスト）のファイルを生成します。このファイルは他のgenerate コマンドでは作られません。

$ rails g integration_test article
      invoke  test_unit
      create    test/integration/article_test.rb

rails generate jbuilder

Jbuilder はJava の統合開発環境…ではなく、JSON をこねくりまわすシンプルなDSL です。scaffold でも生成されています。ビューはなくてもJbuilder のgenerate コマンドはあるんだな、と思ったり。

$ rails g jbuilder article
      create  app/views/articles
      create  app/views/articles/index.json.jbuilder
      create  app/views/articles/show.json.jbuilder

rails generate mailer

メーラーを生成します。こちらもintegration_test と同じで、このgenerate コマンドでしか作られません。

$ rails g mailer article
      create  app/mailers/article.rb
      invoke  erb
      create    app/views/article
      invoke  test_unit
      create    test/mailers/article_test.rb

rails generate task

Rake タスクを生成します。

$ rails g task article
      create  lib/tasks/article.rake

おわりに

今回はRails のgenerator のみ紹介しましたが、他にも色々generator は用意されているので、一度確認してみると良いかもしれません。下記コマンドで一覧が表示されます。

$ rails g -h

またここで紹介したのは生成されるファイルだけでしたが、ヘルプを見ると各種オプションも記載されているので、使用される際にはそちらも目を通してみると良いかと思います。scaffold の場合は下のようになります。

$ rails g scaffold -h

こんにちは、hachi8833です。

今回は棚卸しとして、弊社CTOのbabaさんによるRails勉強会スライドから引用して記事にします。
勉強会自体はRails 3.x時代のものなので既出が多くなっていますが、棚卸しも兼ねて今のうちに記事にいたしました。

非同期処理

言うまでもなく、リクエストからレスポンスまでの時間が長くなるほどユーザー・エクスペリエンスの質が低下します。これを改善するためにさまざまな工夫が必要になるわけですが、その中の一つとして、時間のかかる処理をバックグラウンドで実施しておくというのがあります。

cron

最も素朴な方法はやはりunix標準のcronを使って定時に出力データを準備することでしょう。この場合、起動用スクリプト(rakeなど)やジョブ管理は自分で作成する必要があります。

delayed_job

delayed_job gemを使用すると、ジョブをActive Recordで管理できます。
その便利さについては各方面で語られているので省略しますが、以下の点が少々残念であるという指摘があります。

• ジョブ完了時にキューから該当ジョブを単純に削除するため、完了したのか、Enqueueに失敗したのかわかりにくい
• データをMarshallで渡すため、バージョンが変わったときにトラブルの元になることがある
• Railsが動作していることが前提のため、その分重い

resque

3番手はresqueです。resqueはredis (C言語で書かれたKey-Valueストア) を使用してジョブキューを管理します。Redisとresqueがインストールされていれば、Railsなしでも実行可能です(ActiveRecordがないと使いにくいとは思います)。

resqueはJSONでデータを受け渡しするので互換性が高いのが特長です。

※Redisには少々癖があり、旧バージョンでは書き込みIO負荷が高い・メモリ不足の時に落ちる・expireしても次回読み込みまで消えないなどの問題があったようです(2012年時点の情報なのでその後状況が変わっている可能性あり)。

使い方は以下をどうぞ。

• Railscast
• ASCIICast (日本語)

resqueはgemで拡張するのが習わしになっています。

• resque-scheduler : cronでキューに入れる。[参考]
• resque-lock-timeout : resqueをバックグラウンド実行中にロックをかける。[参考]
• resque-remote: resqueを別サーバーで実行
• resque-pause: 今ひとつわからない

resqueの注意点など

• resqueはマスタープロセスからforkさせてからキューを実行するので、デプロイ時にはマスタープロセスの再起動が必要。
• Workerクラスはモデルの内部クラスとして実装すると見通しがよくて便利です。
• resqueの監視にはmonitが無難でおすすめです(godよりは安定しているみたい)。
• Mysql::Error: MySQL server has gone awayエラーが発生する場合は、最初にActiveRecord::Base.verify_active_connections!を行ってみよう。database.ymlにreconnection:trueと書く手もあるようですが、長いトランザクションの途中でreconnectされると怖いかも。

RubyのWebアプリケーションフレームワークについて

sinatraといえばRubyによる軽量フレームワークとして今や定着しました (一時はRails3の登場で絶滅が危惧されたそうです)。プロジェクトの規模に応じて、RailsとSinatraを使い分け、場合によってはRackを直接駆動するというのがよい感じです。

ちなみに紹介記事を元に生Rackアプリを書いてみたら、えらく簡単でした。

class MyApp
  def call(env)
    [
      200,
      { 'Content-Type' => 'text/html' },
      ['<html><head></head><body><h1>hello</h1></body></html>']
    ]
  end
end

テスト駆動開発(TDD)について

TestFirstとTDDは同じものではありません。TestFirstは単にテストが先行しているだけの状態であり、TDDはテストが開発を牽引しているかどうかという点が違います。

テストのカバレッジですが、一般的に言って100%にこぎつけるのはやはり難しいと言えます。カバレッジにはC0/C1/C2などの段階がありますが、たとえばbegin/rescueブロックをどうチェックするか、fork先のプロセスまでチェックするかなど、追い求めるときりがありません。Coverageは90%を目指すのが現実的だと思います。

xUnit対RSpecという図式について、Railsでは当時からRSpecが支配的だったこともあり、弊社ではRSpecの使用が推奨されてきました。

RSpecでのノウハウ

以下パラパラとメモします。

• テスティングでよく使用されるのはAAAというパターンです。

1. Arrange: 環境のセットアップ
2. Act: テスト対象を実行
3. Assert: 結果を検証

bundle exec rspec spec / --fail-fast

RSpecのマッチャー

RSpecも少し前に3.0が登場しましたが、以前のノウハウもまだまだ健在です。
RSpecのマッチャーで真っ先に覚えるべきはbe_hogehoge系のpredicate(述語)マッチャーでしょう。このマッチャーが機能するには、hogehoge?というメソッドが必要ですので、逆に言えばこのマッチャーが使えるようにコードを書くようにしましょう。ついでながら、このメソッド名もマッチャーがおかしくならないような名前にしておきたいものです。「is_flag?」みたいなメソッド名だとマッチャーが「be_is_flag?」みたいなみっともない名前になるので、そういう名前は使うものではないということがわかります。

他にビルトインのsatisfyマッチャーはブロックを引数に取り、ブロックがtrueかどうかをチェックします。

raise_errorマッチャーは例外が発生するかどうかを確認できるビルトインマッチャーです。例外のテストは意外と忘れがちです。

それから、カスタムマッチャーは遠慮せずにどんどん作りましょう。複雑なオブジェクトをeqで比較できるようにするとか。

UIテストについて

TestFirstが常に善とは限りません。UIを試行錯誤しながら開発するときにはTestFirstはほとんど意味がないのでとっとと諦めましょう。UIにびっしりテストを書いたところで、仕様が変わったときのダメージが大きいので、必要な分だけにしておきましょう。

UIのテストでは、むしろ「/usersだったらuserがたくさん表示されていることを確認する」など、瑣末でない本質的な部分を押さえるようにしてください。後、クライアントの指示で必ず含めなければならない定番の文言があるならそれをテストに含めるのも有効です。

テスト内容がCSSセレクタでデザインに依存するのはよい傾向ではありません。注意しましょう。

テストデータ

単体テストでは、テスト対象以外の関連オブジェクトのデータを作るかどうかが思案のしどころです。大きく分けて、モックでさくさく進めるか、ちゃんとオブジェクトを作成(Object#create)するかです。

• モックは動作も高速で比較的作りやすいのですが、関連オブジェクトの仕様が変わっても検出できないという問題があります。
• Object#createは面倒な代わりに、関連オブジェクトの仕様が変わった場合に検出することができます。

どちらを選ぶにしても、テストをどのように分離し、網羅するかはしっかり考えておく必要があります。単体テストはその対象だけに集中すべきと考えるなら、結合テストで関連オブジェクトとの関係をカバーする必要がある、というふうに。

ところで、テストで時間を扱うにはtimecop gemが便利です。

テスト環境・ドキュメント

CI(継続的インテグレーション)サービスにはtravis CIを始め多くのサービスが出現していますので、積極的に使いましょう。

rspec --format documentation -o 出力ファイル名でRSpecのログを残せます。rspec --format html -o 出力ファイル名とすればHTML形式で出力できます。

自動生成ドキュメントは何かと使いづらいので、必要なドキュメントがあれば自分で書きましょう。

• 主要エンティティER図
• 主要エンティティ状態遷移図
• などなど

active decorator

ヘルパーファイルの命名はビューに依存していて、数が増えてくるとapp/helperの下のどれに追加したらよいか迷ってしまいます。メソッドを追加したいのはモデルであることが多いのですが、モデルが肥大化するのは避けたいものです。

そんなときにはactive decoratorやdraperなどのdecoratorパターンです。full_nameなどのメソッドを簡単に見通しよく追加できます。

decoratorパターンについては『肥大化したActiveRecordモデルをリファクタリングする7つの方法』も参考にしてください。

こんにちは、hachi8833です。これまでチマチマ翻訳してきたRails Guideへのリンクをご紹介します。ガイド全体から見ればまだ半分ぐらいですが、サイズの大きいファイルから先に翻訳を進めてきたので、残っているのは比較的小さなファイルです。

注意: これらのファイルは今のところ翻訳が完了しただけであり、レビューなどはまだ行われていません。各人の責任でご利用ください。

補足: Githubに置いたことでmarkdownは簡易整形されていますが、画像は表示されません。Railsガイド ガイドラインに記載されている方法で Railsガイドをビルドすれば画像+CSSのあるガイドが得られます。
ファイル間のリンクはビルドが前提なので、そのままでは無効です。
訳していて怪しいと思った箇所には●を付けてとっとと先に進んでいます。
原文に忠実な訳とは限りません。原文より情報を増やしたり言い方を変えてあるところが多々あります。
たまに原文のdiffの残りが巨大な文字で表示されていることがありますが気にしないでください。
今後置き場所を移動する可能性がありますのでご了承ください。

Rails Guide (最近翻訳した分)

• Railsをはじめよう (Getting Started)
• Ruby on Railsセキュリティガイド (Ruby on Rails Security Guide)
• Active Supportコア拡張機能 (Active Support Core Extensions)
• Action Controllerの概要 (Action Controller Overview)

Rails Guide (これまで翻訳した累積分)

入門編

• Railsをはじめよう (Getting Started)

モデル関連

• Active Recordの基礎 (Active Record basics)
• Active Recordの関連付け(アソシエーション) (Active Record Associations)
• Active Modelの基礎 (Active Model basics)
• Active Recordコールバック (Active Record callbacks)
• Active Recordクエリインターフェイス (Active Record query interface
• Active Record検証(Validation) (Active Record validations)

コントローラ関連

• Action Controllerの概要 (Action Controller Overview)

応用編

• Active Supportコア拡張機能 (Active Support Core Extensions)
• Ruby on Railsセキュリティガイド (Ruby on Rails Security Guide)

更新情報

• Ruby on Rails 4.1リリースノート (Ruby on Rails 4.1 release note)
• Ruby on Railsアップグレードガイド (Ruby on Rails upgrade guide)

小物ファイル

• Ruby on Railsガイド ガイドライン (Ruby on Rails guide guideline)

Chrome devtools でイベント監視

いろいろなJavaScriptプラグインを使っていると
イベントの伝播を止めてしまうような動作をするものを使ってしまうことがあります。
function を割り当てたいイベントが止められていると厄介です。
代用できるイベントが生き残っていればそちらを使ってしまいたいです。
そんな時、どんなイベントが発生しているのかは Chrome devtools のmonitorEvents で確認することができます。
https://developer.chrome.com/devtools/docs/commandline-api#monitoreventsobject-events

第一引数で監視対象、第二引数でイベントを指定します。

monitorEvents(window, "resize");

イベントの指定はイベント名だけでなく、”mouse” でマウス系のイベントを”key” でキーボード入力系のイベントを指定できます。
配列にして渡せば複数のイベントを確認できます。
省略した場合は全てのイベントが対象になりますが、プラグイン側で独自に定義したイベントは拾えないようです。

イベント監視の解除は

unmonitorEvents(window)

引数は同じです。

Better Errors でエラー確認

link_to :remote 等を使ってAjax 処理を行っていると
例外が発生してもエラーの内容をブラウザで確認できないので
development.log を開いて確認していたのですが、
Better Errors を使っているなら
/__better_errors
にアクセスするだけで簡単にエラーが確認できます。
Better Errors を使うようになって暫くたつのですが、最近までこの機能を知りませんでした。
/__better_errors では直前のエラーを確認することが出来るようです。
https://github.com/charliesome/better_errors/wiki#view-last-error

Better Errors なしだと devtools でエラーが起こったことだけしかわからないですが。

この後はdevelopment.log を確認したりコードを見なおしたり。

Better Errors を入れておけばこのようにエラーの詳細が確認できます。

binding_of_caller も合わせてインストールしておけば、@users が空だということがすぐに確認できます。

これを知ってからAjax処理中に起きたエラーの確認がとても楽になりました。
この機能、README ではなくWiki の方に記載されているのですが、これはREADME にも記載しておいて欲しいですね。