RSpec の動かし方だけは分かってたんだけど、あんまり真面目に整理したことがなかった。少しだけ真面目にドキュメント読んでみた。

基本概念

explicit subject - Subject - RSpec Core - RSpec - Relish

RSpec is a DSL for creating executable exmaples

おぉ、なるほど。

コードが動作例のように見えることが大事ってことか。テストらしく書くのではなく動作例らしく書く。そうすると実行結果のレポートもとても自然に読める。これが設計書のように読める。

基本構造

• ファイル : spec

• describe : example group
  • context : alias of group
    • it : example

it はどこで定義されているのかよく分からないけど

 it 'behavior' do
   ...
   テストしたい振る舞い
   ...
 end

でも

 it {
   ...
   テストしたい振る舞い
   ...
 }

でも良いらしい。it の中身が DSL の力を借りて英文そのもののであれば `behavior' は省略しちゃうという流儀もあるらしい。

cf. RSpec 2 Best practices

でもそれって

日本語でレポートを作れる

っていうメリットがなくなるような？

context ってどう使うの？

describe の alias として context は用意されているが、こんな感じで使うのがいいんじゃないか案。

describe MyClass do
  describe 'this method' do
    context '条件' do       # 英語だと 'in ...' とか 'when ...' とか ?
      it '振る舞い' do
        obj.should be_XXX
      end
    end
  end
end

みたいな感じがE和スタンダードみたい。（間違ってたらツッコンでください！）

確かにこれが自然かも。なるほどなぁ。

Twitter / @SHIBATA Hiroshi: @wtnabe あー、そこについてはケースバイケース …

感心したこと

RSpec って書き方自体は知ってたんだけど、あんまり意味が分かってなかった。あと、読みやすさの代わりに書きにくさがあるなーと感じていたんだけど、これは誤解だなと思った。むしろテストを分類しやすくてとても書きやすい。

これまでも xUnit 系のツールは使っていたんだけど、なんだかとても読みにくくメンテしにくいテストコードを量産していたように思う。少なくとも確認したいことの単位でメソッドを起こしたりはしていなかった。何かを意図していたわけではないけど、一つのメソッドに対するテストメソッドが 3つも 4つもあるのも変な感じがしていたし、メソッド名が長くなりがちなのもいい印象を持てなかった。

それが RSpec だと違和感なく書ける。describe を階層化できるから確認したい振る舞いの名前に重複が発生しない。つまり DRY だ。

もう一つ、diff の出力が素晴らしい。もうほんとこれはすごくいい。これだけでも Test::Unit からの乗り換えに十分値する。

まぁ Test::Unit2 はさらにその上をいくらしいんだけど。

cf. デバッグしやすいassert_equalの書き方 - ククログ(2011-02-28)