アジャイルアライアンスの機能テストツールのグループは、Agile2009の前の日曜日に３回目のワークショップを開催した。 オープンスペースセッションは、機能テスト(ユニットテストに対する)ツーツの技法をさら良くすることに興味がある人なら誰でも参加できた。その他の参加者には、Selenium、SWAT、Cucumber、WebTest、RobotFrameworkそしてTwistの開発者や貢献者もいた。
オープンスペースだったので、アジェンダとセッションは急いで作られた – 今年は4カ所で３つの時間帯でに分けて、12セッションを行うことが可能になった。
Agile Testingの共著者であるLisa Crispin氏によれば、最初のセッションでは、SeleniumやWatirのようには知られていない様々なツールのデモがライトニングトーク形式で行われた。 紹介されたのはCanoo WebTest、Twist、Cucumber、Robot Framework、そしてSWATだ。Lisa氏が言うには“Robot Frameworkが印象に残っています。これはPekka Klärck氏が開発したオープンソースのテストツールで、柔軟性が高いです。テーブル形式を使っているのはFitNesseに似ているのですが、テーブルの種類は1つだけです。キーワード駆動やデータ駆動、さらにはビヘイビア駆動開発形式のテストにも利用できます。コマンドラインの引数も受け付けますし、Swingような内外のライブラリを利用することもできます。 … SWATも面白そうです。いままで誰も見たことがないツールで、特にIDEにに強い印象を受けていた人が多かったように思えます。”
Paul King氏はWebTestやGroovyの開発に貢献しているが、氏が提案したのは、“テストフレームワーク/ドライバ/ユーティリティ/ツールを、もっと混ぜ合わせる必要がある、ということです。彼は、どうすればそれが可能になるのかを視覚的に見せてくれました。テスト実行環境は十分であり、開発者コミュニティは新しい問題を解決することに着目すべきだという考えには、誰もが賛同していました。”
朝のもう1つのセッションは、Matt Wynne氏、Richard Lawrence氏、そしてAslak Hellesøy氏と筆者でCucumber を.NET環境へ移植するには何が必要かについて議論が行われた。そこで明らかになったのは、CucumberのテストをRuby環境で実行する準備をしている限り、Cucumberの.NETへの移植版を開発するのは相対的に単純になるだろうということだった。しかし、それにはCucumberの開発者がテストアプリケーションとシンプルに通信する仕組みを見つけなければならない。この仕組みについては、FitNesse Slimの方法に似たモデルが話題に挙った。セッションの最後にはMatt氏とRichard氏がこの仕組みについて検討し始めた。
昨年のセッションでは、存在するテストツールについてこの場で文書化するべきだという考えに賛同が得られたが、その作業は困難を極めた。今年は、Gerard Meszaros氏がスプレットシート (編集する場合は筆者 mark AT mlevison DOT com に連絡をください) を作った。これは彼自身が朝のツールのデモで見た情報をもとに作ったものだ。午後のセッションのひとつで、参加者が集まりこのスプレットシートにさらに多くのツールの情報を付け加えた。 – 現時点で、このスプレットシートに情報が載っているツールは、SWAT、Cucumber、WebTest、RobotFramework、Twist、TestSwarm、 JBehave、Fit、FitNesse、FitNesseSlim、UltiFit、 Watir、Watin、Abbot、Fest, White、Sahi そしてSahi-Javaだ。Seleniumについての情報がないことが目立つ。
夕方になると、Selenium IDEのようなレコード/プレイバックツールについて議論が行われた。Lisa Crispin氏が考えるにはキャプチャ/プレイバックツールは “新しいツールの使い方を学ぶのに役に立ちますし、テストスクリプトをデバッグしたり特定のテストでつかう正しい宣言を見つけるのにも便利です。でも、 キャプチャ/プレイバック機能ばかり使って、行き詰まってしまうのはよくないです”。Seleniumの開発者であるJason Huggins氏は、Selenium IDE (レコード/プレイバックツール)の一般的な使い方について悩んでいる、と打ち明けた。Selenium IDEはもともとの考えでは、“ジェット機のパイロットが最初に訓練のために搭乗する小さな'訓練機'でした。パイロットは訓練機でいろいろと学べますが、ゆくゆくは本物のジェット機を操縦しなめればなりません”。 この方向性をもっとはっきりさせるのは、以下のような提案だ(以下はMike Longin氏のメモから)。
- Selenium IDEの名称をSelenium Trainerへと変更して、テストの記録が自動化の最終的な目的ではないことをより一層の周知をはかる。
- 複雑さを計測する指標のようなものを作る。この指標は、記録者のレコードが複雑になりすぎてしまっていることを示し、新しいテスト自動化技法を学んだ方がいいということを記録者に伝える。
Mike氏は Paul氏のコメントに答えて、“我々はたくさんのテストドライバやフレームワーク、実行環境を持っているので、そろそろ個々の技法を統合することを見据えてもいいのではないでしょうか。 どのようにすればこれらの優れたツールをすべて、合わせる作業が始められるでしょう。”
Pekka Klärck氏はJennitta Andrea氏とElisabeth Hendrickson氏に、今年もワークショップを実行してくれたことに感謝している。