Proをオープンソース化というニュースが最近出て、少し「あれっ?」と思いました。言うと、googleのこの決定は2010年12月に出たので、ちょっと違和感(いまだに?)がある気がしました。ネットでうろうろしたら、あっ、オープンソース後の初めてのリリースがこのニュースのきっかけかと気づき納得しました。Proを検証する時に手掛かりが少なく、その時にもしオープンソース版が出たら、ぶつかった壁がもう少し和らいだかもしれません(笑)。newを読んでも、別に新しい機能なり、バグ修正なりの情報が全くありませんでした。何の為だった?バージョンを5.1から6.0に挙げただけ?数か月前に検証した状態と変わってないじゃん、なぞなぞですね...。この日本ではあまりなじみのないツールをせっかく検証しましたので、ちょっと古くなったところがあるかもしれませんが(先ほどの確認によると、この可能性もあまりないですね)、ご参考になる方もいるかもしれませんので、情報をみなさんとシェアしたいと思います。インストール(検証はEclipse3.6.2を利用する)。ProはEclipseベースのGUI自動テストツールであり、EclipseのPluginテスト、RCPアプリテスト、SWING・SWTアプリテストなどに対応されています。Coverage確認などの機能が提供されている。テストのフォーマットに準処している。本資料では、テスト関連の機能のみ対象とする。開発元Instantiationsに開発され、googleに買収された後に、Apacheにコントリビューされました。今はApache2ライセンスのオープンソースです。インストール(検証はEclipse3.6.2を利用する)。http://forums.instantiations.com/topic-5-3938.html追加情報:enterTextは上記の対策で日本語キーボードに対応でき、かな入力に対応できそうになるが、どうもenterText自体は、文字一つは一つのキーとして入力しようとする為、“プロジェクト“や“日本語”など、入力できません。マニフェスト名\\myfile.text","ja","JP");また、次のようなコードで再生すると、”:”の問題が解消できたが、その後ろの文字が入力出来なくなってしまった。なし、Linux上でも利用可。ファイルパスなど、OS依存の部分がテストケースにある場合、分岐処理をカスタマイズして対応する必要がある。する必要がある為、同じく分岐処理が必要(OSではなく、OSのデフォルトロケールによって処理を振り分け)。Guide(Eclipseのヘルプ画面)で習得できます。記録機能の設定[*]記録機能を利用する前に、設定が必要です、ユーザガイドに設定方法が紹介されていますが、本検証中に利用している設定を次の通りに例としてリストする。ConfigurationCDEテスト時の注意点[*]Recordする前に、CurlのRTEを終了させる必要がある、CDEのテストを記録する為のEclipseでCDEを起動しない、万が一起動されてしまったら、CurlのRTEを強制でも終了させてください。[*]記録時の環境は英語環境がお勧めです。テストコード・テスト条件・テストケースの作成時に、よく利用するメッセージの特定は英語で確認しやすいためだ。(日本語環境の場合、UIのメッセージ・テキストが日本語になっている為、propritiesファイルが特定のツールを使わないと読めない。ファイルeclipse\com.curl.eclipse.plugin\src\com\curl\eclipse\ui\CurlUIMessages_ja.properties記録問題Curl側の記録ができないJavaのUIしかレコードできない為、VLEやVLEE、ほかのCurlでできたツールのレコードができない。解決策:なしDrag&Dropが正しく記録できないケースがある(手動で追加できるか、確認する必要がある)全く記録されないか、部分的に記録される、再生に利用できないコードになっている。解決策:手動で記録コードを追加する。added.記録漏れがある記録中に、記録漏れが発生する場合がある。:手動で記録コードを追加する。ShellDisposedCondition("Curlメディエーターの開始中"));ご操作などによって余計な操作を記録される場合がある例:Welcome画面の閉じる操作など。解決策:不要なオペレーションが記録された場合に、該当コードをコメントアウトする。記録時に、ダイアログやUIのIDは記録した時の言語設定によって、日本語か英語になるが、再生の環境によって、言語設定が記録時と異なる場合がある。pluginのパッケージに定義されているロケール対応の文字列定数を利用して、対応可能。ShellShowingCondition("Curlメディエーターの開始中"));になるが、パッケージクラスcom.curl.eclipse.InstallHandlerMessagesをインポートすれば、定数を直接利用し、Eclipseのローカライズ機能で対応できる。上記プロパティファイルで対応できるのが、Dialogや、ラベルのメッセージのみで、メイン画面のMenuの場合、plugin.xmlで定義されており、この方法で対応できません。代替案が必要と思われます(制限付きの対応になるなど)記録コードが実行できない場合がある(文法エラー)例:Curlのコード行がある行の横のルーラをダブルクリックする処理を記録したコードは次になっているが、文法エラーです。143));CompositeRulerCanvasがパッケージアクセス属性の為、定義されたパッケージ外からアクセスできない!(のに、記録された)また、$5もなぜ記録コードに入っているか不明(インナークラスのようだが。)、CompositeRuler$CompositeRulerCanvasにある$もdot(.)にすべき。tool(虫眼鏡アイコン)を使えば、記録すると同時に検証条件を追加できる。このツールを起動したら、検証対象のコントロールにマウスホバーをすると、該当対象の検証できる属性が表示されるので、検索条件を記録コードに追加することができる。メニュー・メニューアイテムに対応されてない。対象のプロパティを条件に満たすか検証する。Dialog"));WTは複数種類の条件を検証できる。普通のUI部品の属性検証(使用可否・テキスト・選択・可視性・フォーカス)次の属性条件が用意されている。部品のenabled検証IsEnabledConditionを利用する。LocatorはIsEnabledConditionを使って、enabled属性の検証ができる。部品のテキスト検証HasTextConditionを利用する。LocatorはHasTextConditionを使って、部品に格納されるテキストの検証ができる。実際に、実装された条件であれば、どれでも検証可能だ。検証用ファクトリ便利にコードを書く為、一部のLocatorに条件を生成するファクトリが実装されている。一部の条件で、属性をtrueになっていることを確保(保証)するような書き方もある。それらの条件はcom.windowtester.runtime.condition.IConditionHandlerを実装していて、IUIContext.ensureThat(..)に渡している。0)return;getUI().close(welcomeTab[0]);}手動で条件検証を作成する既存の条件(ICondition)で検証目的に達成できない場合、独自に実装することも可能。条件を検証する処理は、テストスレッドで実装してはいけなくて、UIスレッドで実装する必要がある。テストスレッド側で、検証処理をRunnableを経由して呼び出す必要がある。実装例:ツリーアイテムをドラッグして、別のツリーアイテムにドロップし、一つ目のラベルが期待したラベルになる検証。labelTestCase.assertEquals(EXPECTED_LABEL,tree.getItems()[0].getText());}});上記の条件検証方法があるが、テストケースのメンテナンス性や、実行時の健全性などを考えると、IConditionで実装し、WTの検証条件の仕組みを利用すべき。次の節も参照してください。条件は特定の状態が存在しているかをチェックする為のオブジェクト、ハンドラーは条件がtrueになる場合に起こすべき処理をカプセル化する。条件はテストの実行とテストされているアプリケーションの実行を同調させることができる、あるいはテストで特定のシチュエーションを検証する。UIスレッドのある処理を待つ為に、Thread.sleep(5000);処理より、条件を使えば、テストスレッドとアプリケーションスレッドの同調の信頼性が高くなる。ファクトリを利用することも可能。条件/ハンドラーはペアでIConditionMonitorまたはIShellMonitorに登録され、予想できないイベントへの対処を頑丈にできる。次のサンプルはテストの過程で稀にライセンスダイアログが表示されるケースがあってもテストが正常に遂行できるようにライセンスダイアログが表示されたら"OK"ボタンをクリックさせる為の条件/Handlerを作成し、モニターに登録する。Conditionの場合、CDEで利用しない為、省略。再生時の問題JavaのUIでも、再生する時に、停止されている場合がある対策:ユーザが止まっている個所を確認し、手動でその操作を追加し、その後の再生が継続される。CurlProjectの選択、再生されない場合がある。それは再生時に、Mediatorの起動に時間がかかり、Curlのビューが選択された後に、CurlのメニューがまだEclipseに作成されてない為、次のステップはCurlの新規Projectを作成する処理で失敗する(該当メニューが見つからない)為だ。この問題の対応は、ui.waitの追加が必要。Mediatorにつなぐダイアログの表示・非表示を待たせて、このダイアログが消えたら、次のステップに進むようにテストの記録コードに処理を追加する必要がある。shotsが自動的に作成される。[*]その他メモWelcomeページのテスト[*]デフォルトはEclipseのWelcome画面がテストされません、テストする必要になる場合、次のように、セットアップメソッドのカスタマイズなどが必要です。0)return;ui.close(welcomeTab[0]);}テストケースで保存されてないEditorバッファがある場合の対応。未保存のEditorバッファがある場合、テストが終了できない、または終了に時間がかかる(UIの生成がある為)。それを回避するために、コードでバッファを保存するような処理を書く必要がある。DirtyEditorCondition().test();}}UI部品の特定方法MatcherとLocatorWindowTesterでMatcherとLocatorでUI部品を特定する。finderに代理され、アクティブになっているアプリケーション画面のみ、検索対象にする。テストされているアプリが画面(Window)を持ってない場合、例外がfinderにスローされる。widget)UIの階層構造の調査SWTDebugHelperでUIの階層構造を標準コンソールに出力することが可能。IUIContext.find(ILocator)に代表されるのでILocatorが一つ以上存在する場合、同じようにMultipleWidgetsFoundExceptionがスローされる。IUIContext.findAll(ILocator)マッチしたすべての部品がアレイにセットされ返却される。“OK”ボタンを探すために、ui.find(newButtonLocator("OK"));を使えばいい(もちろん、見つからない、または二つ以上見つかった場合に、例外がスローされる)。ButtonLocator("OK"));を使うと、見つかった“OK”ボタンがすべてアレイにセットされる(空かもしれないが)一般的に、“OK”ボタンが同じ画面上に一個しかないのが普通ですが、複数ある場合に、取得したいボタンの場所、UIの階層情報を利用して、特定できる。このコードは、Compositeの中に入っているボタンを取得する(ほかの“OK”ボタンがこのCompositeに入ってない場合)。確実に部品を特定する方法は部品にタグを付けさせることで、テストケースの開発段階で該当UIにユニークな名前を付けると特定しやすくなる。既存Locatorの動作を変えたい場合や、対象外の部品を特定する為に、Locatorをカスタマイズする必要がある。動作を変えたい場合、IWidgetMatcherを継承し実装する。該当Matcherを呼び出す。対象外の部品を対応する為に、新しいLocatorを作成する必要がある。継承するだけで対応可能。次の例で、EclipseのSection(org.eclipse.ui.forms.widgets.Section)部品の検出に役立つLocatorが作成されている。parent);}}上記の実装は、SWTWidgetLocatorのデフォルト機能を利用している。複雑なロジックについて、例えばツリーの項目選択の制御など、まだドキュメントされてない。対応例もWTのヘルプに載っている。カスタマイズして、特殊なBrowserReferenceを作成する。Components"で検索)。Framework)についてGEFはCDEに利用されてない為、GEF関係のガイドを省略する。