GUIテストは、単体テストよりも時間がかかり、その上難しい。そのため、しばしば広くテスト手動開発チームにおいてさえも、おざなりにされる。2通りの可能なソリューションを検討し、このタスクを一層簡単にすることを約束するSWTおよびSwingアプリケーションのGUIテストを作成する。
GUIテストの記述が難しい理由は何か?一般的にGUIは、クラスの単なるインスタンスよりも多くの設定を必要とする。対話がしばしば非同期であり、マウスが関与するため、ユーザの振る舞いをシミュレートするのは一層難しくなる。GUIテストに向けた1つのアプローチは、テスターを監視し、後に返答可能な スクリプトを作成する、対話レコーダーを提供することである。このアプローチには、複数の問題が伴う。記録形式に基づき、UIでの変更が発生した後、テストの変更が相当困難になりかねない。そのため、当然の如くテスト第一の開発は実行可能ではない。
別の選択肢は、プログラムでテストを作成することである。テストの記述がいかに快適かは、ほとんどフレームワークにかかっている。UIエレメントおよびファシリティーを特定し、非同期操作が完了するのを待機する単純かつ効率的な方法が不可欠である。
SWTBot(リンク)およびMarathon(リンク)はどちらも、Javaアプリケーション向けにGUIテストを記述するためのアプリケーションである。SWTBotは Javaを使用するため、潜在的にJRubyと使用可能である。MarathonはJRuby(あるいは、Jython)を直接使用し、テストをスクリプトする。
SWTBot
SWTBotは、SWTおよびEclipseベースアプリケーションのテストツールであり、SWTおよびEclipseコンポーネントへのアクセスを単純 化するAPIを提供する。テストは、Antタスク経由でも実行可能であるので、継続的な統合構築と統合することができる。Apache 2ライセンスのもと、SWTBotは使用を許諾される。
InfoQはSWTBotのデベロッパであるKetan Padegaonkar氏にインタビューした。Ketan氏はThoughtWorksに勤務しているので、JRubyやDSLで何が起こっているか尋ねてみたい。
これはSWTBotでやるべきことのリストに間違いなく載っていることである。SWTBotにまだ足りない多くのAPIがあり、今あるもので前進するように取り組んでいる。たいていのSWTBotは、Twistの開発チームやSWTBotコミュニティからの要求やフィードバックに基づいてビルドされる。こ れまでのところJRubyの統合に向けた現実的な要求はない。 JRubyを使用してSWT/Eclipseをプログラミングしている人がそれほどいないためなのではないかと、考えている。そこで、今のところ JRubyの統合は後に回しておく。
SWTBot 2.0(現在、ベータ版)は、ウィジェットを検索するために、FluentInterface(リンク)と非常に小さいDSLの組み合わせを提供している。これは、JRubyの方法を完全におこなわずに、前進し、構文上のsugarを十分に提供するためには良い方法であると思う。
SWTBotはレコーダーを提供する。
レコーダーは、概念実証として開発され、あまり触れられていない。多くのコントロールに対するサポートが不足していて、すべての操作を記録するとは限らな い。こうしたサポートを追加するのは取るに足らないことなのだが。レコーダーは、中間フォーマットにコードを記録する。それはAbstract Syntax Tree(リンク)に似ている。そうして記録されたものはそれから、最適な言語で出力可能である。現在、Javaをサポートしているが、Rubyさえも可能である。
注：テストの記述に記録および再生は、非推奨である(TestingGUIApplications(リンク)およびRecordingとCodingの比較(リンク)を参照 のこと)。ワークフロー(またはすべてのスクリプト)の完全なスクリプトが、ちょっとした変更でも再記録されなければならないことが主な理由である。 SWTBotは、PageObject/ScreenObject(リンク)パターンを使用することを勧めている(または、機能テストの再利用(リンク)を参照)。
では、今後の計画はどうするか?
SWTBotは、多くの方法でかかわっているすべての人にとって、学習体験である。現状のSWTBotは、3度目の再書き込みである。2.0で修正された1.xの誤りはかなりの数があった。
Java 1.5、特に汎用で利用可能な新しい機能を使用するため、Java 1.4コードべースを移行した。また、SWTBotのいくつかのサブシステムを切り離した。それにより、マルチページエディタ、Eclipseリッチ フォームエディタおよびGEFをサポートするために、SWTBotはより拡張可能になる。
SWTBotをeclipse.orgに移行する提案(リンク)もある。SWTBotがますます多くのユーザにとって、アクセス可能なものになり、すべての人のためになる。
SWTBotでテストするためのコツは、David Green氏のブログ「Eclipse GUI Testing Is Viable With SWTBot(リンク)」にも載っている。
Marathon
SWTBotに反して、MarathonはSwingアプリケーションのテストに使用可能である。Marathonには、独自のエディタおよびテストランナーが付属しており、またデバッグをサポートし、Ant タスクを提供する。MarathonはBangaloreのJalian Systemsによって開発され、GNU LGPLでライセンス交付を受けている。Marathonの維持者であり、中心的な開発者であるDakshinamurthy Karra氏に話を聞いた。
SWTよりSwingアプリケーションをテストするためのツールが多くあり、そこで、SWTへのサポート追加計画があるのかどうか尋ねた。
Eclipseをベースにした、商用バージョンのリリースを計画している。しかし、さまざまな理由で予定が遅れている。数ヵ月以内にリリースしたいと思っ ている。チームとして、すぐさま取り組まねばならないことは、MarathonにWebテストサポートを追加することである。需要次第では、SWTに対す るサポートの追加を受け入れる。これまで、SWTよりもWebアプリケーションサポートに対しての要求が多かった。
MarathonはJRubyおよびJythonをサポートする。これらの言語を選択する理由は何であったか?
Jythonは元のデベロッパが選択した言語だった。個人的には、Rubyが好きなので、JRubyサポートが追加された。Marathonのアーキテク チャは、接続可能なスクリプトモデルをサポートする。JVM(Groovy、Bean shell、Clojure)でサポートされるすべての言語を追加することができる。
Rubyの方を好む別の理由は、DSLを作成する機能である。キーワードベースのテスト(リンク)をMarathonに追加する(まだ初期の)計画があった。
そうは言っても、他の言語をサポートするためのコミュニティからの寄与を受けるのは、うれしい。
Marathonのスクリーンショット(リンク)を見ると、インターフェイスはEclipseと似ているが、関係があるのか?
Eclipseプラットフォームに基づいた、商用バージョン(暫定名：MarathonITE - Marathon Integrated Test Environment)をリリースする予定である。Eclipseは、最適な開発プラットフォームであり、UIがEclipseに似ているのはそれが理 由の1つである。機能を実装するための正しい方法を探る必要がある場合、たいていEclipseがどのようにして実装するのかを確認する。
Marathon(OSSバージョン)をIDEに統合する計画はない。
テストにJRuby (of Jython)を使用すると、動的言語をより保守的な開発環境へと連れ込む絶好の機会となり得る。
どのようにUIテストを作成するか?
原文はこちらです：http://www.infoq.com/news/2008/10/gui-testing-jruby