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

Ruby on Rails: The RSpec Book 読破記録: 10章から13章まで

■10章からはBDDの実情をコレまでのプロジェクトの進め方について比較しながら説明がされます。
●従来:
計画 > 分析 > 設計 > コーディング > テスト(ユーザー受け入れテスト、パフォーマンステスト) > 導入
●アジャイル:
・ プロセスやツールよりも個人との対話
・包括的なドキュメントよりも動くソフトウェア
・契約交渉よりも顧客とのコラボレーション
・計画に従うことよりも変化の対応
というマニフェストどおり、短いイテレーションを繰り返しながら作り上げる手法
●BDD
従来のものよりもアジャイルの方法がよいが、その方法をとることが難しいので、それをなるべく簡単に(というか確実に)するためにあるのがBDDだと読み取りました。

■11章からは「BDDとは何か」というような内容です。
●原則
・十分といったら十分
・ステークホルダーに価値をもたらす
・すべては振る舞いから

●フィーチャー(ステークホルダーが考えるひとまとまりの機能)=[ストーリー,ストーリー,ストーリ](実装する段階でひとまとまりにできるもの)
●ストーリーとは
・タイトル
・ナラティブ ←誰が[ステークホルダー]がこうしたい[フィーチャー]ので~~[利益]
as a [ステークホルダー], I want [フィーチャー] so that [利益]
もしくは
in order to [利益], a [ステークホルダー] wants to [フィーチャー]
・受け入れ基準 ←シナリオ=[ステップ,ステップ,ステップ] ←所有者はテスター
[The one where] the account is locked
[The one where] the password is invalid
それぞれのステップが、前提・イベント・結果のいずれかにあたる。シナリオを必ずこの3つでそろえる必要はない。
シナリオはステークホルダーが行うことと同じ方法でアプリケーションとやり取りするようにする。
シナリオは必ずしも統合テストである必要はない。つまり機能の部分を切り出して行うことができるということだと理解しました。

■12章ではようやくRspecの記述方法や用語の意味を説明してくれています。
・サブジェクトコード  ←RSpecを使って振る舞いを指定するコード
・エクスペクテーション ←期待される振る舞いを表現したもので、サブジェクトコードに書く。(Test::Unitでいうアサーション)
・サンプルコード ←サブジェクトコードの使用法と、特定のコンテキストにおけるエクスペクテーションの実行可能なサンプル。。意味がわかりません。とにかくサブジェクトコードのまえに書く。これを記述する意味は設計とドキュメント化のためであり、ついでにこれはテストになる、と。(Test:Unitでいうテスト)。つまり設計やドキュメント化でもあるテストといったところですかね。
・サンプルグループ ←サンプルコードのグループ(Test::Unitでいうテストケース)
・スペック ←サンプルグループを記述したファイル。

用語の説明のあと、Rspecの構文に関する基本的なメソッド・保留のやりかた・before,after,around・ヘルパーメソッドの共有とサンプルの共有・入れ子のメリットデメリットなどを説明してくれます。

■ 13章ではエクスペクテーションの説明があります。
オブジェクト.should expectation
オブジェクト.should_not expectation
●expectation
include (something)
respond_to(something)
raise_error(sometiong)
●等価評価のいろいろ
○オブジェクト.should == something
×オブジェクト.should != sometiong
○オブジェクト.should_not == something
●そのほか、有働小数点演算のときどうするか・評価文が複数行にまたがるときどうするかなどがの説明もあります。
●shouldのほかにexpect{}.to change{}をつかって状態の変化が正しくされているか評価する方法が示されます。
changeの後にはchange{}.to()、change{}.from()、change{}.by()と続きます。
●エラーを期待する例も紹介されています。
expect{do_something_risky}.to raise_error
●期待される異例な状況を表現するためのthrow/catchもここで説明されます。
lambda{do_something_risky}.should throw_symbol
?expect toと同違うんでしょう?そもそもlambdaって いう単語を知らないので調べてみたらラムダ計算というのがあるみたいですね。expectとの違いは使いどころであり、代替可能なこともわかりました。
●空のマッチャとしてarray.should be_emptyが紹介されます。
●同様にRuby述語に対応していることが示されます。これを述語マッチャというらしいです。
user.should be_in_role(“admin”) は user.in_role?(“admin”) == trueと同じ
他にも
user.should be_a_~~やbe_an~~というように使ってもいいと。
でもparser.should be_can_parse(“sometext”)というのは動作はするのだがおかしい文になってしまうので、カスタムマッチャを作成してなんとかすることもできると。これは後で説明するとのことです。
●このような工夫が他にもあることの例としてmethod_missingとマッチャを組み合わせることが紹介されます。
request_parameters.has_key?(:id).should == true

request_parameters.should have_key(:id)
と表現できる。have_で始まるものをhas_と解釈してくれるらしいです。
●そのほかにもコレクションに対する評価方法について、コレクションを持っているパターンとコレクションが持っているというパターンでの書き方を紹介しています。
field.players.select{|p| p.team == home_team}.length == 9←フィールドにいるホームチームを取り出して、数が9であることを確認している。

home_team.should have(9).players_on(field)←ホームチームのフィールドにいるプレーヤーが9にんであることを確認している。
この例の場合はhome_teamオブジェクトにplayers_onメソッドがあることが前提となっている。ない場合はNoMethodErrorが発生する。

collection.should have(37).items
「この場合のitemsは純粋な糖衣構文です。」意味がわかりません。。Wikipediaによると糖衣構文 というのは人間にとってわかりやすくすることを目的として作られた構文ということらしいです。これ(have)について後で説明するとあるので、その時点でわかることを期待します。
●文字列もコレクションだといいます。
“this string”.should have(11).characters
●コレクションに対するエクスペクテーションの精度を表現する方法が説明されます。
haveの亜種として
・have_exactly() = have()
・have_at_least()
・have_at_most()
が紹介されます。
●haveの仕組みがここでやっと説明されます。
have()メソッドは戻り値がRSpec::Matchers::Haveクラスのインスタンスです。
コレクションに期待される数で初期化されてます。
result.should have(3).things は result.should(Have.new(3).things) と同じであると。
私なりの理解ではhaveはHaveクラスを3で初期化します。3で初期化されたHaveクラスは「コレクションの数は3に違いない」という意気込みを持ちます。resultには(変数でもメソッドでもとにかく)thingsが必要で、それがコレクションだとHaveは考えます。そしてHaveはそのコレクションのlength(なければsize)をみて3かどうかを評価すると。
要するに3とresult.things.lengthを評価しているのと同じになりますね。「人間にとってわかりやすくする」というのは時にややこしくするという側面をもちます。文章としてみたときはわかりやすいが、構文としてみたときにはブラックボックスが増えているということです。実際にlengthとsizeの意味が違った場合にややこしいことになると本文中でも指摘されています。

●演算子を使う有用なケースについて、1~10の数字を乱数として10000回出力したうち1000回ぐらいは1がでるが、ばらつきがあるはずなので出る回数を980~1020であれば問題ないとする場合
it “10000回ためしたら1は10%ぐらい出現するはず、ばらつきがあっても±2%(980~1020回)になるはず” do
result.occurrences_of(1).should be_greater_than_or_equal_to(980)
result.occurrences_of(1).should be_less_than_or_equal_to(1020)
end
↓演算子のほうがわかりやすいかも
it “10000回ためしたら1は10%ぐらい出現するはず、ばらつきがあっても±2%(980~1020回)になるはず” do
result.occurrences_of(1).should be >= 980
result.occurrences_of(1).should be <= 1020
end
使える演算子は==,=~,be <,be <=,be >,be >=です。
●ここで自動的に生成された説明についての考察がなされます。それが表現したいものになることはほとんどないので、どのように対処するかについてふんわりとした意見が書いてあります。
● サンプルの主語を明確にするためのsubject()メソッドを使用してbeforeブロックでのインスタンス変数を定義する代わりに使用すると同時に、itなどのを直接書くことができるようになります。javascriptのwith構文のような感じに見えます。
describe Person do
subject{Person.new(:birthdate => 10.years.ago)}
specify{subject.should be_eligible_to_vote}
end

describe Person do
subject {Person.new(:birthdate=> 10.years.ago)}

it {should be_eligible_to_vote}
end
●暗黙的な主語が説明されます。subject構文がない場合にdescribeの後に指定したクラスをnewしてsubjectとして使用するらしいです。当然この構文が使えるのはインスタンス化に引数がないものに限られます。
describe RSpecUser do
it{should be_happy}
end

いやー。長い章でしたが、RSpecに関する胸のつかえがとれた感じがします。
RSpecはテストと同時にドキュメントでもあるので、人間によって文章として読みやすくすることがひとつの重要な役割です。
そのため糖衣構文をふんだんにつかう必要がありました。故にブラックボックスは増え、どのように記述すればよいかについてリファレンスを追っていっても単に記憶されるだけで、仕組みとしては理解できないので、なんとなく腑に落ちない状況でした。似たようなことがRubyを勉強したときもありましたが、それよりもさらに高度に(いい意味で)ややこしくされています。
また、describeもcontentもitも動作としてはほとんど同じだという点も、この仕様を受け入れづらかった原因でした。「このようにも書けるし、このようにも書ける」といったことが多く、いたずらにメソッドを増やしているようにしか思えませんでした。そういうわけで「テストする」ということに思考の視点があるときは一体どれを書けばいいのか迷うことが多々ありました。「仕様は頭の中にある。はやくテストをしなければ」とあせっていたわけです。それよりもまず「仕様」を書きましょうと。それが「テスト」になりますよと。いろいろな書き方をマスターすることで、思考の視点を「仕様を書く」ということにシフトできれば、すらすらと書けるようになる気がしてきました。

Ruby on Rails: The RSpec Book 読破記録: 1章から9章まで

RSpecに関して勉強を始めて1週間たったのですが、なかなか日本語での情報もなく、バージョンが違ったりすることでも戸惑い、テストをするためのコーディングにえらい時間がかかり、本末転倒の状態にありました。よい情報はないことかと調べたら「The RSpec Book」という本をみつけ、さっそく購入。

この手の洋書を翻訳したような本は、サンプルを進めていくとつまづくことも多いので、記録を残すことにしました。
この記録はこの本を読んで行く中での感想や考察あるいは単にメモです。 要点をまとめたようなものではありません。つまりこの本を手に取っている方が、別の人間がどのようにこの本を読んだか知ることによって理解を深めることに役立つか、この本を買おうか悩んでいる人がざっとどんな本なのかを知ることに役立つか、そのどちらかだとおもいます。

まず、適当なフォルダを作って、
gem install rspec –version 2.0.0
gem install cucumber –version 0.9.2

を実行する。ちなみに環境はWindows7上のVirtualBox上に作ったUbuntuです。

cucumberのインストール時になにやらエラーが発生。
ERROR: Failed to build gem native extension.

ネットで調べたがよくわからず無視、とにかく先に進みます。
■14ページの
cucumber features
で予想された出力と違うものが出現。
undefined method ‘describe’ for main:object (NoMethod Error)
ネットで調べると同様のエラーがありました。

どうやら本ではファイルのおき場所が
・/hello/数字/features/greeter_says_hello.feature
・/hello/数字/greeter_spec.rb

となっているが、先述のリンク先のように
・/hello/数字/features/greeter_says_hello.feature
・/hello/数字/spec/greeter_spec.rb

としなければなりませんでした。疑問はのこるものの、先に進みます。

■3章を通過したところで疑問は増していきます。サンプルどおりにコードを作っていっても実行するところがなく、「あ、これは説明だけなのね」とわかります。

■気にせず4章に入ってすぐに「ダウンロードファイル」とあります。なに~~。このような本にダウンロードコードがあることは普通でしょうが、こんな本の途中にURLが記述されているのは珍しい。。3章までで不要なコードを書かされた(構成上しかたのないことであるとはわかっていますが)ので今後はダウンロードしたコードを使うことに決めました。
先ほどのディレクトリの間違いもここではっきりしました。ダウンロードファイルのなかでは正しく、本通りにすすめると必ずエラーになるようです。

■5章の終わりにプログラムを実行する場面があります。環境によってちょっとコードを変えなければいけないようですが、私の環境ではダウンロードしたコードそのままで実行できました。

■ひとつのコードを書いては説明があり、それが9章まで続きます。丁寧すぎていらいらするぐらいです。この時点ではじめのプロジェクトは終了し、アプリケーションを一つ作ったことになっています。 しかし、計画>コーディング>デバッグやリファクタリングというやり方になれすぎてしまっているのか、そもそもテストを書くことへの難しさを感じざるを得ず、生産性が本当にあがるという実感が持てません。単純なアプリケーションを作るだけでもコレだけのテストが必要であることを思うと、好意的に見れば、もしこれを行わない場合、アプリケーションのリリース時には未テストの状態である項目がどれだけあるか、悪寒を感じます。一方で、コレだけのテストを実装前に書き出すことができるのか、などという漠然とした不安があります。ただこのBDDという手順を踏むことで別の不安を取り除くことができ、テストの書き方さえ慣れてしまえばそこにかかる労力よりもはるかに多くのものを得られるような期待感をもって10章へ進みます。

Ruby on Rails アノテーション TODO,FIXME,OPTIMIZE

後から実装はアノテーションのコメントをいれて後で参照する。

コードに下記のように入れておくと

def validate_each(record, attributes, value)
  # TODO: 後から実装
end

下記のコマンドであとから参照できる。

$ rake notes

ウィンドウズだと日本語が文字化けするらしいので注意

Ruby on Rails 3.2.0 ビヘイビア駆動型開発RSpecのスタートアップ

アプリケーションが複雑になってきて、疎結合でがんばっていてもどうしてもひとつ直すと一方に影響してしまう状況になったので、やっぱりテストもきちんとしなければと思いなおし調べた結果、RSpecというのがどうやらよいらしい。

一応デフォルトのTest:Unitを使っていたのですが、どうせ本格的に導入するならみなさんが「いい」といっているほうがいいにきまってます。

ということでRSpecをはじめました。

が、情報が少ない!いきなりつまずいてしまいました。

ネット上の記事によっていろいろ違うことが書いてあります。どれも環境によって使い方が違うのか、短い間に仕様がいろいろ変わったのかなと想像していますが。
なのであくまで私の環境においてどのようにはじめたかを記述します。

環境は下記のとおり

  • OS:Windows7上にVirtualBoxにてUbuntuをインストール
  • ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
  • Rails 3.2.0

まず、インストールです。Gemfileに下記を記入

gem ‘rspec-rails’, ‘>= 2.6.0’, :group => [:development, :test]

$ bundle installを実行してインストールされたことを確認。

次にプロジェクトにRSpecを初期設定します。
$rails g rspec:install

この状態でscaffoldなどを使うと自動的にspec/のなかにmodels/hoge_spec.rbなどのファイルができます。

これらのファイルは自分で作ってもOKなのですが、だーっと作ってもらえるのはやっぱりうれしい。
ところが私の場合プロジェクトの途中ですのですでにたくさんのモデルやcontrollerを作ってしまっていました。

すでに存在するものに対してspecファイルを作るには以下のとおり。

$ rails generate rspec:model Hogehoge

コントローラも同様に作れる模様。

その後で
$ rake  spec
ですべてのテストを実行できます。

■なやんだところ

一部の記事にはRSpecをインストールした後、
$ spec -v
でインストールされたかどうかを確認する。とありましたが
$ rspec -v
で確認することができました。

Gemファイルとして提供されているものではなくRailsのプラグインとして導入するよいと薦めている記事もあります。 これによってその後の操作が違うようです。

Ruby on Rails Ver.3.2.0: generate scaffoldを取り消す手順

$ rails destroy scaffold 取り消したいScaffold名

でappのmodel,view,controllerの各要素やhelper,javascript,stylesheetなどgenerate scaffoldで作られたものがすべて削除される。

が、DBが残っている。

のでそれも消す。下記はsqlite3でgtoupsテーブルを削除する例

sqlite3 db/development.sqlite3 #接続
sqlite> .tables #テーブルがあることを確認
sqlite> DROP TABLE groups; #削除
sqlite> .tables  #テーブルが削除されたことを確認