Cucumberは巨大で多くのコンポーネントの集合体です。また構成もいくつか種類があり、試験対象のアプリケーションによって時に構成を変える必要があります。今回はCucumberの構成についてまとめ、選択肢について簡単に解説していきたいと思います。
まずはCucumberの依存関係を覗いてみましょう。アウトラインを把握するだけのためで、構成の選択肢とは関係ありません。
$ gem dependency cucumber --version 0.6.2 --remote
Gem cucumber-0.6.2
term-ansicolor (>= 1.0.4, runtime) #標準出力に色をつける
treetop (>= 1.4.2, runtime) #Ruby用の構文解析器生成系の一つ
polyglot (>= 0.2.9, runtime)
builder (>= 2.1.2, runtime)
diff-lcs (>= 1.1.2, runtime)
json_pure (>= 1.2.0, runtime)
nokogiri (>= 1.4.1, development) #HTML解析
prawn (= 0.6.3, development) #PDF出力
prawn-format (= 0.2.3, development)
rspec (>= 1.3.0, development)
syntax (>= 1.0.0, development) #Rubyコードのシンタクスハイライチィング
spork (>= 0.7.5, development) #テストサーバ
代表的な構成
単体でCucumberを動かすときは基本的に必要なコンポーネントはcucumberのみです。ただし、rubyのコードを試験したい場合はcucumberのみがセットアップされていれば動作しますが、pythonを試験するときはrubypythonが必要で、Javaを試験するときはjrubyからcucumberを動作させる必要があります。
参考 Python JRuby and Java
Web applicationを試験したい場合に選択肢が非常に多くなります。ここに代表的な構成を示しておきます。
Test Suite for TDD
+cucumber
|
Test Suite for Web App
+webrat
||
|Mode
|+selenium
|+mechanize
|+rails
|
+capybara
||
|Driver
|+selenium
|+celerity
|+culerity
|
+watir
|
browser
+firewatir
+safariwatir
+chromewatir
+celerity
ブラウザテスティングツールについてはruby-toolbox.com(ライブラリ比較サイト)がよくまとまっているので参考にされると良いと思います。簡単に解説します。
Webrat - Webアプリケーションの受け入れテストを簡単に綺麗に書くためのツール。
それそのものはブラウジングを行いません。seleniumやmechanizeが行います。JavaScript非対応。
Capybara - Webratと同等の機能を持つテスティングツール。すべてのブラウザに対応する事を目指している。
すべてのWebアプリケーションを試験できるわけではなく対応しているのはRack applicationのみ。
Xpath, Javascript, AJAX対応
Celerity - HtmlUnitのJRuby wrapper。Javaのheadless browser(UIなしブラウザ)です。JavaScript対応
Culerity - CucumberとCelerityを統合します。JRuby対応
Watir - 様々なブラウザに対応したテスティングツール。JavaScript非対応
その他の構成
Ruby on Railsを試験するときの構成オプション
ruby script/generate cucumber --webrat | --capybara | --rspec | --testunit | --spork
webrat, capybaraに関しては上記したとおりなので割愛します。rspec, testunit optionはstepsの実装をrspec, testunitで書くということではないかと思います。資料が見つからなかったので実装の仕方は分かりません。
Sporkオプションはscript/spec_serverに似ています。script/spec_serverはテスト用のDRubyサーバです。Railsの環境をロードしてテストコードがDrb越しにアクセスできるようにします。
Spork - テスト用のDRubyサーバ。サーバのコピーをテスト毎にフォークします。カーネルのフォークを利用するのでPOSIX準拠のOSでしか動作しません。SporkはDRbのオーバーヘッドがあるためシナリオの動作は遅くなります。代わりにシナリオを動作させるまでのRails framewokとrubygemsのロード時間を短縮します。つまり、シナリオの数が少ない方がSporkを利用する価値があります。複数になるとある時点でSporkを使っていない場合と速度が反転します。Cucumberのドキュメントによるとそれは"プロジェクトによるが１０ー２０シナリオ前後"であると記されています。
＊ Cucumber実行時に--drbオプション(次回以降に扱います)を付けることでfeaturesはSporkサーバ内で実行されます。Rubyインタープリタのプロセスにはロードされません。
.
