月別アーカイブ: 2012年3月

Ruby on Rail 3.2.0 + cancanで意図しないActiveRecord::RecordNotFoundが起こる件

たとえばpeople_controllerのshowで

def show
@person = Person.find(params[:id])
respond_to do |format|
format.html
end
rescue ActiveRecord::RecordNotFound
back_to_index
end

とか書いてあるとき、対象IDのPersonが見つからなければrescue文を通るはず。

RSpecのテストでも
Person.should_receive(:find).and_raise(ActiveRecord::RecordNotFound)
のように書いて試したらきちんとrescue文を通りました。

一安心したところ実際にブラウザで試してみると画面に ActiveRecord::RecordNotFound例外が表示されます。

??なぜ

ログを見るとcancanがそれ以前にfindメソッドを呼んでる。どうやらココで例外が起こってしまっているようです。

当然といえば当然の結果。こちらによると作者は404エラーを起こすべきと考えているようです。正しいように思います。
どうしても修正するにはプラグインの挙動をいじらないと。。

プラグインの中で起こるエラーについて捕捉するにはapplication_controller.rbの中でrescue_fromを書くのがよいけれど、

rescue_from(ActiveRecord::RecordNotFound) {
#処理
}

これだとすべてActiveRecord::RecordNotFoundエラーがココを通ってしまうので、どうなんだろう。。

Cucumber+CapybaraでXPathを用いてセレクトボックスで選択できる値があるかどうかを調べる

<select id=”user_role” name=”user[role]”><option value=”admin”>admin</option>…</select>

とかあるときに選択できる値を持つoptionタグががあることをテストするためにXPathを使いました。正直XPathは避けていたがそれほど難しくはなさそうです。

ならば /^roleのセレクトボックスにadminが存在するはずだ$/ do
page.should have_selector(:xpath,’//select[@id=”user_role”]/option[@value=”admin”]’)
end

こちらを参考にしました。

Viewのテストには重宝しそうです。

Ruby on Rails 3.2.0 RSpec 2.8.0でActiveRecord::RecordInvalidのテストでargumentの数が違うと怒られる

以下のようにActiveRecord::RecordInvalidのテストをしようと思いました。

let(:person) { mock_model(Person).as_null_object }
it{
Person.should_receive(:find).and_return(person)
person.should_receive(:update_attributes!).and_raise(ActiveRecord::RecordInvalid)

}

が、

ArgumentError:
wrong number of arguments (0 for 1)

と怒られます。なかなか情報がなかったのですが、RecordInvalidクラスがコンストラクタでnewをするときにActiveRecordを引数としてとるらしく、それがないので怒られたようです。下記のようにするとよいです。

person.should_receive(:update_attributes!).and_raise(ActiveRecord::RecordInvalid.new(person))

エラー表示はどのタイミングでエラーが起きたのかというのをもっと詳細に知らせてほしいものです。テストをするといろいろなことが知れて、そういったよい面もありますね。

 

Ruby on Rails: The RSpec Book 読破記録: 15章から18章

■15章ではRSpecを快適に使うためのTipsが書かれています。

RSpec実行のオプションやエディタ、オートメーション化、Rake、RCovなどが紹介されています。

私はすでに紹介されているいくつかを開発環境に導入済みです。Ruby on Railsを使っているのでRake、それからrspec_railsRCovはよく知っています。Autotestは使っていませんが、同様の機能をGuardで実装しています。またエディタはTextMateの評判がいいのですが、LinuxなのでGeditプラグインをいくつか入れて使っています。Redcarも使ってみたのですが、日本語がどうも、、私には合いませんでした。

■16章ではRSpecをカスタマイズして使う方法が紹介されています。

・実行するサンプルとしないサンプルを分ける。
・モジュールを追加する
・before,after,aroundのグローバルフック
・14章でもすこし説明されていたMockの選択
・カスタムマッチャ
・カスタムフオーマッタ

などです。中でもカスタムマッチャはよく使いそうです。

RSpecをカスタマイズするのはもう少しデフォルトの状態に慣れてからでもよさそうです。デフォルトの状態でも十分に高機能だと感じていますし、現段階でわからないことがあってもいいかなぁと思います。さらに読み進めます。

■17章は「Cucumberの紹介」とあります。

Cucumber= Cucumberフィーチャー + Cucumberコマンド + ステップ定義
Cucumberフィーチャー = タイトル + 自由形式のナラティブ + いくつかのシナリオ
シナリオ = 任意の数のステップ

いくつかのポイントが説明されています。
・フィーチャのタイトルは短く簡潔に
・ナラティブはConnextraフォーマットを用いて記述しましょう
As a <role>
I want <feature>
So that <business value>
↓ 日本語で書くと
<だれだれ>が
<なになに>したいので
<なぜなら>これこれこういうことをしたいからだ
のようになります。うーん。。

Cucumberのファイルの頭に
#language: ja
と記述するとCucumberが日本語でも記述できます。もともとが英語なのでどうしても不自然ではありますがそれでも日本語で記述できるのはありがたいことです。対応する日本語訳は次のようにするとヘルプを見ることができます。
cucumber –i18n ja

・シナリオは成功するシナリオ(ハッピーパス)から書き始めて、いくつかの特異なケースを追加していきましょう。
・シナリオに対し、ステップを追加していきます。そのとき
Given、When、Then、And、But
で始まるステップキーワードを用います。日本語だと
前提、もし、ならば、かつ、しかし
となります。

・この時点でcucumberを実行するとステップのコードが出力されるのでそれを利用して、ステップファイルを作成しますが、それについては後で説明するとのことです。
・ケースバイケースでステップを一つ一つ細かく書いたり(命令型)、ざっくり書いたり(宣言型)しましょう。
・シナリオが多い場合はfeaturesディレクトリの中に任意のフォルダに分けてfeaturesファイルを整理しましょう。
・タグを活用しましょう
シナリオにタグをつけると後で、そのシナリオだけ実行したり、させなかったりできます。

■18章ではCucumberについてのより詳しい説明がされます。
シナリオに定義されているステップの中で、ステップの内容が定義されていないと、cucumberを実行した際に定義すべきコードが出力されますので、それをfeatures/step_defenitions/の中の任意のファイルに定義します。定義は正規表現になっており、キャプチャグループが引数として扱われます。正規表現そのものを書くことは少ないですが、すこしでも使ったことがないと理解が難しいかもしれません。

使ったことがない人へのヒントとしては「/」で始まって「/」で終わる。「/^」が文頭で「$/」が文末。「([^”]*)」というのは簡単にいう「なんらかの文字」という意味です。この()カッコでくくられたものがキャプチャグループです。それでそこにマッチした文字列が引数となりますよ。と。

RSpecと同じようにフックもあって、タグごとに別のフックを付けられたりすることも説明されています。
カスタマイズはWorldオブジェクトを使います。

ステップ定義の中で別のステップを呼び出せる説明されています。たとえばさまざまなログインをまとめて定義したいとき。

When /^I am logged in as admin$/ do
When I am logged in as “admin”
end
When /^I am logged in as “([^”]*)”$/ do |user_role|
end

とするといいらしいです。別のステップを呼び出すときにそのステップに引数を渡す場合「”」はエスケープしましょう。

When /^I am logged in as “([^”]*)”$/ do |user_role|
When “The email is \”#{user_role}\”@example.com”
end

ステップ内のテーブルを用いて、まとめて複数のテストをしたり、初期設定であらかじめデータを作っておくようなテストをしたりできます。このことははじめのほうの章で簡単なアプリケーションを作ったときに体験しました。

17章と18章はCucumberのざっとした概要になっており、前の章で簡単なアプリケーションを作成するときに使ったテクニックのおさらい+もうちょっと突っ込んだ内容になっています。Cucumberのリファレンスがあればそれを読んだほうがより詳しく知れますし、RSpec同様読んだからといってマスターするまでは至らない程度のざっくり感です。

19章はいよいよRailsではどのようにすればよいのかという一番知りたかった内容が書かれています。

Cucumber1.1.9, capybara1.1.2で日本語を使用するとき便利なステップの定義

たとえばadminしか新規ユーザーを作成できないという仕様で、adminの場合だけユーザー作成画面を表示できることをテストをしたい場合、結果をStep文に含めてしまうと便利なことがあります。

#language: ja

フィーチャ:新規ユーザーの作成
ユーザーとして
新規ユーザー作成画面を表示したい
roleによって新規作成できることを制限したい。

シナリオアウトライン:admin以上であればユーザー新規作成画面を表示できる。
前提 role”<role>”としてログインしている
かつ “ユーザー新規作成画面”へ行く
ならば “<message>”と表示され<boolean>はずだ

例:
| role | message | boolean |
| admin | CanCan::AccessDenied | ない |
| manager | CanCan::AccessDenied | |
| staff | CanCan::AccessDenied | |

上記の場合は表示され(る)か(ない)が入るので、ステップ定義で

ならば /^”([^”]*)”と表示されるはずだ$/ do |message|
page.should have_content(message)
end
ならば /^”([^”]*)”と表示されないはずだ$/ do |message|
page.should_not have_content(message)
end

とすると日本語に結果を含めることができてとてもわかりやすくテストが実装できます。

ちなみにユーザー関係の実装はDeviseを用い、roleによる権限はcancanを用いました。上記の例ではCanCan::AccessDeniedが表示されるかどうかをテストしていて、adminの場合は拒否されないので表示されないことが確認できます。

お客さまと話をするとよく出てくるIT業界へのクレームから学ぶ

お客さまと話をしているとIT系の人にたいするクレームが出てくることがあります。真摯に受け止め、うちではそのようなクレームがでないように努めたいです。

その1、ぼったくり。
これが一番おおいです。
・ドメインの更新料10万円とられた。
・サーバー代金初期費用100万円で月10万、後で知ったが格安レンタルサーバーだった。

などなど、そのような話をお客様から聞くと心が痛みます。 大きなプロジェクトであれば、単なる請求書の数値あわせである場合もあるかと思いますが、小さな会社さんのITに対する夢を打ち砕くような状況もよくあります。私の父の会社も使いもしないホームページとEメールアドレスの発行に莫大なお金を払っていたことを後で知りました。

IT業界は黎明期に新しい技術や用語を武器に、なんとなく景気がよかったですよね。その頃といまとを比べたらサーバーも高価だったり、技術者も情報量も少ないゆえの希少性だったり、そういうまっとうな理由がありますので、安易に「ぼったくっていた」とは言い切れないです。市場が成熟して競争がされると値段が安くなりますし、市場自体が広がっていますからそれだけで各サービスの値段は下がっていくのが自然です。お客さんのクレームの中にはその頃支払ったお金と、いま同じことを発注するのに支払うお金とを比べて「ぼったくられた」といっている場合もあります。ですが、そうやって大目にIT業界を擁護しても擁護しきれない現時進行形の「ぼったくり」にもよく遭遇します。

・昔の値段がそのままの場合
・担当者のキックバック代が上乗せされている場合
・見積もっている人がよくわかっていない場合
・悪意のある場合

ぼったくり = IT業界全体。 この印象を抱いている人は多いです。日本人特有の「やさしいお客さま」が光だとすれば、その影です。それに密接に関係するのが次のクレームです。

その2、難解すぎるヨコモジ。
つぎからつぎへと知らない単語が繰り返されると、よくわからないから任せてしまいたいと思うかもしれません。自分の頭がわるいといわれているようで腹が立つかもしれません。「サーバー」「ドメイン」などは代表的なIT用語といえますが、それでさえ普通に暮らしていたら知らなくてよい言葉です。次から次へと登場するIT用語ですが、お客さんが知らなくてはならない用語はひとつもないです。専門用語ですから、専門家がしっていればよい言葉です。そうは言ってもサービスの名前(ツイッターなど)や企業の名前(グーグルなど)は仕方ないです。外人だと思って覚えていただくしかありません。IT用語はものすごい勢いで増えていっていますので、現役で活躍している技術者でさえ覚えるのが大変です。非常に高度な専門性が要求される業界であるという意味では「~~士」と呼ばれる人々(たとえば弁護士)と同じような職種といえますが、一方では若い方を中心に「作り手よりもよく使いこなす人々」もいるという特徴もあります。わからない用語を並びたてられたら、遠慮なく「もっとわかりやすく言って」といってください。わかりやすくいえなければ、話している人自身がよくわかっていない可能性があります。

その3、すぐ「できない」という。
私もいってしまうときがあります。つい。
・予算的にムリ → ムリをすると食べていけなくなります。
・時間的にムリ → ムリをすると体を壊します。
・技術的にムリ → 自分じゃできないこともありますし、誰にもできないようなこともあります。
・倫理的にムリ → 法律にふれるようなことはできません。
・体制的にムリ → 毎日決まった時刻に手動で更新したいとしたら、ある程度の人員が必要です。

理由はさまざまですが、精一杯がんばっても困難なときがあります。

「できないできないってなんでできないの?」ITの仕事の多くはコードを書くことでしょう。そのコードは難解な数式のように見えます。コードが数千行になることは普通で、数千行あるコードが数千を超えるファイルになることも珍しくありません。それらのコードは一文字も間違ってはならず、足りなくてもいけません。そういう世界の話です。

一口にITといっても、内科・外科など医術の世界と同じように得意分野があります。具体的にこれがやりたいということがあれば、それを得意とする人を探してください。苦手とする人に頼むと、見積もりが非常に高い場合があります。もっとややこしいケースでは、低く見積もりすぎて後でトラブルになったりします。

発注会社を選択するコツはもっとあります。ホームページを作りたいというシンプルな要望であっても、それがもたらす目的や効果がご自分ではっきりとしていない限り、われわれが行うお仕事は「ホームページを作ること”だけ”」ではありません。ホームページは場所のようなものです。八百屋をつくるのと大規模商業施設をつくるのとは違うことは誰もが知っていることですが、「ホームページをつくる」という単純なオーダーについても同様な違いがあります。単純作業ではないのです。ですから制作会社が「ホームページ制作~万円」という料金体系にするのはわかりやすくすることが目的であって、本当は心苦しいはずです。

「載せる内容・広告戦略・機能」の三拍子をご自分で計画できる自信があるか、担当の方があなたのビジネスに関してとても親身になって考えてくれるか、あるいは事がそう難しくないか、そのいずれかでなければ不幸な結果になります。ある程度ビジネスが複雑で、ご自身ですべてを把握するのが難しく、お願いする担当者があなたのビジネスを単純に見すぎているとすれば、考え直す時です。

 

ビジネスとは別に、システムというややこしい要素がこの業界にはつきものです。システムは建築と似ています。構造的で、使うものであり、メンテナンスが必要で、いずれ作り変える必要があります。作って終わりではないのでシステムをつくった人間・企業とずっと付き合っていけそうかどうかは、好き嫌いも含めてとても重要なことです。

最後に、コンサルティングという罠。
専門性という意味でわれわれの仕事にも「~~士」と呼ばれる職種と同じような側面があるということを述べました。「~~士」というのはコンサルタントと似た部分がありますよね。私が日々お客さまと話をしていると似たようなことをしているなと感じることがありますし、お客さんからそういわれることもあります。「Facebookのコンサルティング」「クラウドのコンサルティング」「SEO」「アフェリエイト」など、難解な道具を専門的に教えてくれる人たちがいます。かれらはあなたのビジネスに自分の専門分野を役立てたいと考えています。しかしあなたのビジネスがそれだけで成り立つわけがありません。おいしい料理を作ることがあなたのビジネスだとすれば、彼らがいうことは「この包丁がいかに切れるか」「この鍋がいかにすばらしいか」といっているのと同じです。違うのはよく切れる包丁かどうかを知るのは簡単なのに、このヨコモジがどれほど役立つのかは難しいということです。ドブに捨ててもいいほどのお金と時間があるか、全面的に信頼して任せられる人がいる場合を除いては、あなた自身がそれらがどのくらい役立つかわかるまで、それらに手を出すべきではありません。

 

というわけで

・ぼったくらない
・わかりやすく話す
・できないといわない
・お客さまのビジネスを考える

ということを軸にこれからやっていきたいと思います。

 

Ruby on Rails Ver.3.2.0 DeviseのControllerをカスタマイズしたときにRSpecを書いてつまずいた記録

Deviseのコントローラをカスタマイズするためには、config/routes.rbを下記のように変更します。
devise_for :users, :controllers => {
:sessions => “users/sessions”,
:registrations => “users/registrations”,
:passwords => “users/passwords”
}

この例ではdeviseをuserとして使っている場合です。

この場合はapp/controllers/配下に新しくusersフォルダを作成しますが、app/controllers/配下に直にファイルを作成してもOK。
ちなみにそのばあいは:sessions => “sessions”とかになります。

また、session用、registrations用、passwords用と作っていますが、deviseに設定した機能によっても違いますし、もちろんカスタマイズの必要がなければ書かなければいいだけのことです。自分が使っているdeviseのcontrollerを知りたければrake routesで調べましょう。

app/controllers/users/sessions_controller.rb
app/controllers/users/registrations_controller.rb
app/controllers/users/passwords_controller.rb

を作成してそれぞれdeviseのクラスを継承します。sessions_controllerの場合は書きのような感じ。

class Users::SessionsController < Devise::SessionsController
end

app/controllers/直下にsessinos_controllerを作った場合は
class SessionsController < Devise::SessionsController
end
となります。

これであとはメソッドをオーバーライドするなり、before_filterをつかって処理を追加するなりすればいいです。
これで一通り動作することを確認。

ところがRSpecファイルでテストを書こうとすると、

Failure/Error: get(:create)
AbstractController::ActionNotFound:
Could not find devise mapping for path “/users/sign_in”.
Maybe you forgot to wrap your route inside the scope block? For example:

devise_scope :user do
match “/some/route” => “some_devise_controller”
end

みたいなエラーがでます。

下記のようにdeviseのmappingを指定する処理を各テストの前に実行すればよい模様。

before do
request.env[‘devise.mapping’] = Devise.mappings[:user]
end

エラーメッセージにあるようにconfig/routesのセッティングが間違っているのかと散々悩みました。

 

Ruby on Rails: The RSpec Book 読破記録: 14章から

■14章ではRSpec::Mocksについて説明されます。
あるオブジェクトがそれ単体で動作すればこれを使う必要はありません。通常はなにかほかのオブジェクトとのコラボレーションによって機能を果たします。しかし、それらのチェーンを追っていくと結局のところすべてのオブジェクトを作ってからようやくひとつのテストができあがるという事態になりかねません。事実私はRSpecを勉強しだした時に、Ruby on RailsのScaffoldを使ってかたっぱしからオブジェクトを作ってしましました。。オブジェクトをとりあえず作ること自体は合っていました。方法が間違っていて、scaffoldを使うべきではなく、RSpec::Mocksライブラリを使うべきだったのです。
●テストダブル←モック・スタブ・フェイク・スパイともよばれる。テストダブルといったときに、それが意味するものがいろいろであるため、混乱する。double,stub,mockメソッドは動作は同じで意味が違う。違いは後ほど説明するとのこと。
● メソッドスタブ ←とりあえず期待するレスポンスを返すようにするメソッド。
●メッセージエクスペクテーション ←一度も呼び出されないとエラーになる。
●メッセージエクスペクテーションは実際にアサーションであるが、アサーションされるのはコードが最後まで通過した後なので、Given Then Whenがわかりづらくなることが指摘され、それを解決するTest Spyパターンが存在することが紹介されています。ただ、私にはそれほどわかりづらいとは感じられず、むしろnot-a-mockやRRを使うほうが難解に思えました。たぶんこれらの説明が少ししかないからなので、後ほど調べてみようと思います。

●テストダブルを使うことによってデータベースから切り離してテストを行うことができると説明されています。Railsの場合はモデル、つまりActiveRecord=データベースのようなところがあるので、モデルのテストではテストダブルはそれほどつかわないだろうなと想像できます。逆にコントローラーではモデルのロジック(メソッドの内容)と切り離してテストがしたいので、これらを使わない手はないですね。

●ショートカット
customer = double(‘customer’)
customer.stub(:name).and_return(‘Bryan’)

customer = double(‘customer’, :name => ‘Bryan’)

複数でも指定できます。
customer = double(‘customer’)
customer.stub(:name).and_return(‘Bryan’)
customer.stub(:open_source_projects).and_return([Webrat’,’Rack::Test’])

costomer = double(‘customer’, :name => ‘Bryan’, :open_source_projects=> [Webrat’,’Rack::Test’])
※ここまで長いと逆にややこしいかも

●スタブチェーン
※ある執筆者が書いた新しい書物を取得する(RoR上のコード)
Article.recent.published.authored_by(params[:author_id])
↓スタブチェーンで実装すると
article = double()
Article.stub_chain(:recent, :published, :authored_by).and_return(article)
とする。オブジェクトが入れ子になっている場合に奥のほうのメソッドをスタブ化したい場合に便利。

●カウント(メッセージエクスペクテーションが呼び出される回数を指定する)
hoge.should_receive(:fuge).exactly(1).times #1回hoge.fuge()が呼ばれる
hoge.should_receive(:fuge).exactly(5).times #5回hoge.fuge()が呼ばれる
hoge.should_receive(:fuge).at_most(5).times #5回までhoge.fuge()が呼ばれる
hoge.should_receive(:fuge).at_least(5).times #5回以上hoge.fuge()が呼ばれる

1回の場合と、2回の場合はショートカットがある。
hoge.should_receive(:fuge).once #1回hoge.fuge()が呼ばれる
hoge.should_receive(:fuge).twice #2回hoge.fuge()が呼ばれる

●一回も呼ばれないことを期待する
hoge.should_not_receive(:fuge)
↓そのほか、あんまりつかわなそうな書き方
hoge.should_receive(:fuge).never
hoge.should_receive(:fuge).exactly(0).times

●この引数で呼ばれるはずだと期待する
hoge.should_receive(:fuge).with(50)
hoge.should_receive(:fuge).with(50, something)

●引数がこのインスタンスであることを期待する。
hoge.should_receive(:fuge).with(instance_of(Fixnum))
※通常はこのやりかたはオススメしないとのこと。そのサンプルの意図をはっきりさせるためであればつかってくれと。。しかし、どうしてオススメしないのかはかかれていません。たぶんテストで使われるデータには具体的な数値や文字などが使われる方が好ましく、そうであれば型をチェックする理由はないからなのかなぁと想像しています。

●なんらかの引数があることを期待する
hoge.should_receive(:fuge).with(anything())
hoge.should_receive(:fuge).with(anything(), 50)

●withがなければどんな引数でも受け取るけど、あえてそれを明示したい場合。
hoge.should_receive(:fuge).with(any_args())

●引数なしで呼ばれることを期待する
hoge.should_receive(:fuge).with(no_args())

●引数がハッシュのときに中身まで期待する
hoge.should_receive(:fuge).with(hash_including(‘A’=>1,’B’=>2))

●逆に引数がハッシュのときに中身にふくめてはいけないことを期待する
hoge.should_receive(:fuge).with(hash_not_including(‘A’=>1,’B’=>2))

●正規表現も使える
hoge.should_receive(:fuge).with(/.*User/)

●カスタムマッチャも使える※ある数よりも大きいことを期待するカスタムメソッドの例
hoge.should_receive(:fuge).with(custom_method(3))
#methodはクラスを返す
def custom_method
CustomClass.new(expected)
end
#classは「==(actual)」というメソッドを定義する。←そうすると後で呼ばれるらしい。
#description()メソッドを定義をしておけばエラーが起きたときのメッセージを指定できる
#initialize()メソッドを定義してクラス変数を保存すればより使いすくなる。
class CustomClass
def initialize(expected)
@expected = expected
end
def description
“#{@expected} より大きい”
end
def ==(actual)
actual > @expected
end
end

●連続して値を返すことを期待する ※本の中ではネットワークの接続を3回まで試すことを題材に説明しています。
hoge.should_receive(:fuge).and_return(nil,nil,nil)#hoge.fuge()はnilを3回返す
↓こうも書ける
hoge.should_receive(:fuge).exactly(3).times.and_return(nil)

●エラーが発生することを期待する
hoge.should_receive(:fuge).and_raise

●エラーの型を指定できる
hoge.should_receive(:fuge).and_raise(InsufficientFunds)

●エラーの型を指定したいが、そのエラーに引数がある場合は一度インスタンス化してそれを渡す。
instance = InsufficientFunds.new(:reason => :on_hold)
hoge.should_receive(:fuge).and_raise(instance)

●エラーではなくてシンボルを渡したいときはand_throw
hoge.should_receive(:fuge).and_throw(:insufficient_funds)

●正しい順序で呼ばれることを期待する
hoge.should_receive(:first_method).ordered
hoge.should_receive(:second_method).ordered
※逆に言うとorderedを付けないと順序は無視。
※ひとつのオブジェクトのみに有効。複数のオブジェクトに指定しても順序無視

●スタブは上書き可能
before do
@logger = double(‘log’)
@logger.stub(:log).and_return(nil)
end
it ‘test’ do
@logger.should_receive(:log).with(‘something text’)
end
※この使えばデフォルト値を設定できるのでコードを簡潔にできるときがある。 多用すると複雑になるかも。

●テストダブルの使いどころ
・まだ作ってないオブジェクトに
・ネットワーク、サーバー、ファイルシステム、などの外部システムに
・動作に時間がかかるオブジェクトに
・そのほか不確定になりすいオブジェクト

● モック作ると役割が見えてくることがある。状態ではなくやり取りに合わせる。と説明されています。
確かにモックを使えば、あるオブジェクトがそのモックにほしいメソッドを書きたくなるので、役割・メソッド(インターフェース)が見えてくる気がします。 あるオブジェクトに別のオブジェクトに必要なメソッドがわかったときに、そのオブジェクトに直接ロジックを書き始めるよりも、とりあえずメソッドだけ定義しておいて、モックを使ったほうがひとつのオブジェクトに集中できるし、視点が「使う側」なので、相手を「なんらかの仕事をする者」として見れますよね。

●リスクとトレードオフ:やりすぎには注意しましょう!
・1つのサンプルでモックの数が増えたら、結びつきがつよくなっているかも
・テストダブルを入れ子にし始めたら、それらを分離できる証拠
・「とりあえず」で指定したモックは偽のOKを出す危険があるので、高レベルの自動テストを導入しよう

●ここで、他のテストダブルフレームワークの使い方の説明がされます。
RSpec::configure do |config|
config.mock_with <フレームワークID>
end
フレームワークIDには:rspec,:mocha,:flexmoch,:rrのいずれかがある。デフォルトは:rspec

●その他を使うにはカスタムアダプタを作成します。とあり、MockFrameworkAdapterの内容について説明されています。
RSpec::configure do |config|
config.mock_with CustomMockAdapter
end
※そのファイルをどこにおけばいいかについては触れられていないのですが、どうやらコレのことらしく、私の環境の場合は以下のディレクトリでした。
~/.rvm/gems/ruby-1.9.2-p290/gems/rspec-core-2.8.0/lib/rspec/core/mocking

 

いやー。14章も長かった。
正直な話、14章を一度読んでも何にもわかりませんでした。例を交えてわかりやすく説明してくれているのですが、サンプルコードのキモがドコなのかわからず、本文がどこを指しているのかわからなかったからです。実装経験の多い方であればおそらくすぐにわかるのだと思いますが、Rubyでさえ初心者の私には無理でした。

くじけそうになりましたが、避けて通れないと思い直し、わからないながらもこの先の章をだーっと呼んでいくと、19章からRailsに対しての記述があります。そこを読み進めていくと、おー、わかるわかる。

途中で本を読むのをやめて、今進めているRailsのプロジェクトにわからないながらRSpecやCucumberを実際に使ってみました。

その後で14章に戻ってくると、前はわからなかった概念がよくわかるようになっていました。

ここまで読んできてこの本は、実践に則してよくまとめられている一方で、文章がなぜかわかりづらいと感じます。内容が抽象的な概念を説明してたりするので、主語述語やセンテンスの関係性があいまいな日本語にそのまま変換すると、わかりづらくなるんですかね。

とはいえRSpecを題材にした日本語の書籍といえば、現段階ではほぼこの本だけですから、ありがたく読ませていただきます。15章につづく。