Ruby

opensocial-ruby-clientのドキュメントがあまり無くて結構苦労した。

まず、opensocial-ruby-clientはRailsありきなんだけど、そこで修正が必要。

これは自分のプロフィールとマイミクとかをとってくるコード。mixi用のConnectionがないので自分で作る必要があり。

これまた、割と今更なエントリ。当日は@t_wadaさんのお誘いでRubyグループのコーチ役として参加したけどあまりコーチらしいことしてないな・・・申し訳ない。

TDD Boot Camp(以下tddbc)では、午前中に @t_wada さんと Lasse氏 の講演、午後は各言語ごとにグループを作りペアプログラミング。朝から夜にかけてがっつりなイベントだった。TDDをやりたくてもやり方がわからない、やってみたはいいけど上手くいかないって人にはとてもいいイベントだったんじゃなかろうか。実際、僕も色々と得るものがあった。

とりあえず、当日のお題をあとで自分で書いたものを晒しておく。スレッドセーフ以外の仕様変更まで取りこんである。

http://github.com/ukstudio/LRUCache

これは1つのクラスにまとめてあるけど、結構複雑な感じになってきているので、CacheItemみたいな感じでもう1つ別のクラスを作ってそっちにキャッシュの保存期限とか持たせた方がいいかもしれない。仮にここからクラスを抽出するとしてこれだけテストが書いてあればそんなに苦労せずに抽出できるはず。テストがあるからこそクラスを抽出させるという変更も恐れることなく対応できる。

Fixnum#seconds_laterはLasse氏のを参考にした。個人的にStubの影響をブロックの中だけに限定させたかったので少し修正してある。あとは、Rspecの機能で言うと、subjectやカスタムマッチャを使ってる。それぞれそんなに難しくないので使ってみることをおすすめする。

最後にちょろっと感想を伸べておくと、tddbcはとても素晴しいイベントだったと思う。 @ebackyさんや、来日してくれたLasse氏をはじめ、スタッフのみなさん、今回このようなイベントを開催してくれて本当にありがとうございました。また参加された皆様からも色々な気づきを得られました。ありがとうございます。

僕はTDDでプログラマの階段を更に1歩登れたように思う。ハッキリ言って、TDDを知る前と知った後のコードにはかなりの差がある。なにより、TDDでのプログラミングは楽しい。tddbcに参加された皆様もこの楽しさを知ってもらえればと思う。

Object#send(__send__)ならメソッドの呼び出し制限に関わらずメソッドを呼び出すことが可能なので、privateメソッドもテスト可能。

確か、1.9以降はメソッド呼び出し制限がObject#sendにも影響するとどこかで見た記憶があるのだけど結局そうはなっていないみたい。

1.9.1、1.8.7で確認済み。

ちなみにオマケ。

Pythonはメソッド名の前にアンダースコアを2つけるとprivateなメソッドになるのだけれど、実際のところ別名でメソッドを定義してそちらを呼び出してるっぽい。別名で定義された方はprivateではないので、そちらを呼び出してテストすることが可能。

他にもJavaだったらsetAccessible(True)を実行すればpublicなメソッドに変更されるのでテスト可能。と聞いただけで確認はしていない。

第21回　Railsアプリの受け入れテストをCucumberで書こう

榊さんの紹介で、Ruby Freaks Loungeに記事を書かせて頂きました。ありがとうございます。内容はCucumberについて。割と自分のブログに書いた内容や、WEB+DBのRails特集で書いたことと被ってるかな。

あともう一回、記事を書く予定なのでそっちでは実際にRailsアプリのテストをCucumberで書く記事にするつもり。チュートリアル形式的な。

感想とか突っ込みとかあれば教えて頂けるとうれしいです。次回もお楽しみに。

現在は、以下の方法よりrvmを使うことをオススメします。 10/05/28 追記

ローカルに開発環境としてRuby1.8.7とRuby1.9.2を共存させる方法。

Rubyのインストール

まずはRubyの処理系をインストール。ruby-lang.orgから適当に落とす。今回はruby 1.8.7-p174とruby 1.9.2-preview1を使用。

まず、Ruby1.9.2から。

$ ./configure --prefix=/Users/uk/local --program-suffix=-1.9.2
$ make
$ make install

–prefixでインストール箇所を指定。自分の$HOME以下のどこかにいれるのが最近のマイブーム。この後でてくるgemも$HOME以下。Rubyはともかくgemは$HOME以下を推奨する。ある程度有名なライブラリならいいが、適当な野良ライブラリをインストールするにはこちらの方が安心な為。

–program-suffixを指定するとインストールしたバイナリの後ろに指定した文字列を付加できる。この例だと「ruby-1.9.2」となる。他の処理系と分けるためこの指定は必須。

次に同じ要領で1.8.7もインストール。やることは同じ。

$ ./configure --prefix/Users/uk/local --program-suffix=-1.8.7
$ make
$ make install

これでそれぞれのバイナリが/Users/uk/local/binに入っている状態となる。

RubyGems

次にgemの設定。Ruby1.9からはgemが標準で入っている為、インストールは必要ない。ただバージョンが1.3.4なのでアップデートしておくといいだろう。

1.8.7は別途gemをインストールする。RubyForgeにプロジェクトがあるのでそこからダウンロードしてくる。

$ ruby-1.8.7 setup.rb

それぞれのgemのenvを見ておくと、インストールしたライブラリがどこに保存されるかわかる。

$ gem-1.9.2 env
$ gem-1.8.7 env

それぞれ、GEM PATHSの先頭が/Users/uk/local/lib/ruby/gems/1.8と/Users/uk/local/lib/ruby/gems/1.9.1(何で1.9.2じゃないのかはわからん)になっているはずだ。今後、gemを使ってライブラリをインストールするときはsudoは必要ない。

シンボリックリンク

この時点でRuby1.9.2とRuby1.8.7がそれぞれ使える状態になってはいるが、いちいちバージョンを指定するのも面倒なので、シンボリックリンクで対応する。riとかも必要に応じて作る。

$ ln -s ~/local/bin/ruby-1.8.7 ~/local/bin/ruby
$ ln -s ~/local/bin/irb-1.8.7 ~/local/bin/irb
$ ln -s ~/local/bin/gem-1.8.7 ~/local/bin/gem

Ruby1.9.2を使いたいときは、一度シンボリックリンクを消し、再度作りなおす。

とは言え、その作業を手動で行うのは手間なのでスクリプトで対応するのがオススメ。5分ぐらいで書いたスクリプトをgistに貼っておいた。実行権限を与えて、引数にバージョンを与えると使えるはずだ。PATHとCMDは適当に書き換えること。そのうちもうちょっとマシなものに書き直すかも。

まとめ

とりあえず、こんな感じでRuby1.9.2とRuby1.8.7を共存させてみた。いくつか、気になる点があって例えばgemでRailsをインストールするとシェバングが「#!/Users/uk/local/bin/ruby-1.9.2」となっており、シンボリックリンクを用意しただけではダメな時もある。その時はとりあえず諦めて以下の様に実行している。

$ ruby -S Rails hoge

実際にこの環境で開発するのはこれからなので、もしかしたらそのうち色々な問題もでてくる可能性はあるが、とりあえずこの環境でやってみようと思う。

OAuthの細かい説明は抜き。

まず、OAuthを使うためにはTwitterでアプリケーションの登録が必要なので、http://twitter.com/oauth_clientsで登録をしておいてください。 以下のコードの6行目の部分を取得したConsumer keyとConsumer secretをに置き換えてください。

適当なところからverifyアクションにリダイレクトしてくると、さらにTwitterにリダイレクトします。その後、callbackアクションに戻ってくるので、そこで認証して取得したトークンをUserモデルに保存します。(ここでは自分のサービスにログインしているユーザが認証を行っています。)

その後、保存したトークンを使ってTwitterに発言をします。リクエストが受け入れられなかった場合の処理などは省いてます。

Twitterには取得したトークンに有効期限はありませんが、有効期限が存在するものもある(どちらかというとそっちの方が多いのかも)気をつける必要があります。

ちなみに細かいことを調べていないので「トークンをDBに保存してしまっていいのか」とか「トークンが外部に漏れてしまった場合はどうしたらいいのか」などについてはよくわかっていません。

WEB+DB PRESS Vol.51
	WEB+DB PRESS編集部 技術評論社 2009-06-24 売り上げランキング : 130 Amazonで詳しく見る by G-Tools

僕個人っていうわけではないですが、会社の人達と一緒に6月24日発売のWEB+DB PRESS Vol.51で執筆させて頂きました。初めての執筆活動なので、読みにくい部分、至らない部分などあると思いますが、買って読んで頂けると幸いです。

今までメール(ActionMailer)のテストはどうにも面倒で、自分でブラウザから動かしてログを見てってやっていたんですが、Cucumberでメールのテストもできるっぽいので試してみました。

確認環境はRails2.3.2、Cucumber0.2.3、email_spec0.0.10。

email_specはgithubをsourceに指定してインストールすることができます(bmabey’s email-spec at master – GitHub)。config/environments/test.rbあたりに書いておくといいと思います。

email_specをインストールするとgenerateにコマンドが追加されています。

$ ruby script/generate email_spec

ここで生成されるfeatures/step_definitions/email_steps.rbは英語なので日本語に直したものを使います。

これは僕がこないだ出向していたときのプロジェクトに使われていたものなので、多分その出向先の誰かが作ってくれたものだと思います。ありがとうございます。

最後にemail_specを使えるようにfeatures/support/env.rbに

require 'email_spec/cucumber'

を追記してやります。あとはシナリオにテストケースを書いてテストすればOKです。

 ならば "example@hoge.com" がメールを1通受信していること

ちなみにメールの文章中にあるURLに遷移することもできるので、例えば仮登録→メールで認証URL→本登録という流れもちゃんとテストできます。

ちょっと大げさなタイトルかもしれないですが、個人的にはそれぐらいの感動。「これで勝つる!」な気分。何に勝つのか知らないけれど。

今までのRailsのテストはもっぱらRSpecで書いてて、確かにこれはこれで素晴らしい。採用当初はバグが減ってその時も「これで勝つる!」な気分でした。でもやっぱり受け入れテストがネックになるんですよね。Seleniumとかも使ったりしてましたけど、ブラウザががちゃがちゃ動くし、なんとなく面倒で結局手動で確認という感じになってしまいました。

そこでCucumberの登場ですよ。個人的に素晴しいと思うのは

• テストケースが自然文(っぽい)
• そんなに邪魔じゃない

あたりかなぁ。テストケースが自然文っぽいというのは実はかなり大事で例えば

お客さん: まずトップページにアクセスするとログインフォームがあって、そこにログインすると「ようこそ!ほげほげさん」と出すようにして欲しい

っていう要望、つまりユーザーストーリがあった場合に割とそのままシナリオとしてテストに変換できる。

もし トップページ にアクセス
かつ メールアドレス に hogehoge@hoge.com と入力
かつ パスワード に hogehoge と入力
かつ ログイン ボタンを押す

ならば ようこそ!ほげほげさん と表示されること

これは疑似言語とかじゃなくて、これがそのままテストとして実行できる。つまり今までこっちがブラウザをポチポチしてお客さんに「できましたー(多分)」と報告していて、お客さんからすると何をどうテストしていたのかが曖昧という問題があったのだけれど、 Cucumberだとお客さんと一緒に受け入れテストを作ることができて、そのテストケースもお客さんが読むことができるから曖昧さが消えて安心が生まれる。

もちろん開発者にもメリットはあって、Cucumberはユーザ視点レベルのテストだからテストとしては一番外側なテストでここのテストがちゃんと通っていれば、アプリケーションの動作がユーザ視点での正しく動くという保証ができるわけです。

その保証ができるとどうなるかと言うと、極端な話、ユーザ視点での動作が正しければ内部の動作なんて割とどうでもいいわけで、内部に自由がでてきます。内部に自由がでてくると、コードの修正や設計の変更が怖くなくなり、リファクタリングがしやすくなります。結果、メンテのしやすいアプリが出来上がります。

Cucumberは残念なことに、Ajaxのテストができないのでその辺りはSeleniumや手動での確認、あとはjsonやxmlを吐き出すアクションをRspecでテストするなど臨機応変に対応する必要がありそうです。

最後にオマケですが、僕が実際にCucumberを使ったときの開発の流れをば。

• Cucumberのシナリオを書く
• Rspecでモデルのテストを書く
• モデルにロジックを書く
• Rspecでコントローラとビューのテストを書く
• コントーラとビューを書く
• Cucumberのテストが通ったのを確認して、実際に手動でも確認する
• それぞれのテストをautotestとかでまわしながらリファクタリング

まず最初にCucumberのシナリオを書きます。仕様のブレを防ぐためです。この時点では当然Cucumberのテストは通りませんが、とりあえずモデルからビューにかけてボトムアップでコードを書きます。基本的にテストファーストです。

ビューまで書いたらこの時点でCucumberのテストが通っていれば手動で確認、通っていなければ同じ要領でテストファーストでコードを書きます。

最後に今まで書いたテストが落ちないようにリファクタリングを行います。ここまでで1つのユーザストーリ(Cucumberでいうフィーチャ)の実装が完了します。

CucumberはRspecの時もそうでしたが、新しく導入するときにどうしてもコストがかかります。でも慣れてくればそのコストは大分減りますし、stepもある程度使いまわせるものが多いので長期的に見れば逆にコストが減ると思っています。個人的にはCucumberを採用しない理由はないと思うので、この記事を読んでいる人も是非試してみてください。

名前、長いよね。accepts_nested_attributes_for。以下、ネストしたって言います。長いので。

最近はもっぱら日本語化はi18nにしてるんですが、今回ちょこっとこのネスト関係ではまったのでメモ。

とりあえずモデルの作成までガッとやります。Railsのバージョンは2.3.2です。最下行はgemのインストールが必要です(http://github.com/amatsuda/i18n_generators/tree/master)

それぞれアソシエーションとバリデーションのコードを追記しておきます。当然、accepts_nested_attributes_forの記述も必要です。その辺の詳細は省くので適当にググってみてください。

で、日本語化はモデルを作成した後に行なっているのでとりあえずカラムは日本語化されてる筈です。その辺の詳細も省きます。

されてるはずなのですが、一部日本語化されてない箇所があるのでこれを日本語化させます。

userモデルのところにentries_xxxが追記されています。ちなみにhas_oneの場合はentry_xxxになります。xxxはカラム名。

おわり。