質問

コード内の計算は十分にテストされていますが、GUIコードが非常に多いため、全体的なコードカバレッジは思ったよりも低くなっています。ユニットテストGUIコードに関するガイドラインはありますか?理にかなっていますか?

たとえば、アプリにはグラフがあります。グラフのテストを自動化する方法を理解できていません。グラフが正しいかどうかを確認するには、人間の目であるAFAIKが必要です。

(Java Swingを使用しています)

役に立ちましたか?

解決

MVPやMVCなどの設計では、通常、実際のGUIからできるだけ多くのロジックを抽象化しようとします。これに関する非常に人気のある記事の1つは" The Humble Dialog Box" マイケルフェザーズ。個人的には、ロジックをUIから外そうとすることで、さまざまな経験がありました。非常にうまく機能することもあれば、価値がある以上に面倒なこともありました。ただし、私の専門分野の範囲外です。

他のヒント

もちろん、答えはMVCを使用し、できるだけ多くのロジックをGUIから移動することです。

そうは言っても、SGIがOpenGLを新しいハードウェアに移植しているとき、同僚に一連のプリミティブテストを実行して、一連のプリミティブを画面に描画してから、フレームバッファ。この値を既知の適切なハッシュ値と比較して、APIがピクセルごとに正確かどうかをすばやく判断できます。

試してみることができます UISpec4J は、SwingベースのJavaアプリケーション用のオープンソースの機能および/または単体テストライブラリです。 ...

ヒントを次に示します。

GUIからできる限り多くのコード(コントローラーとモデルオブジェクトがある)を削除して、GUIなしでテストできるようにします。

グラフィックについては、グラフィックを生成するコードに提供する値をテストする必要があります。

Cucumber および Swinger :Swing GUIアプリケーションの機能受け入れテストを英語で記述します。 Swingerは、NetbeansのJemmyライブラリをフードの下で使用してアプリを操作します。

Cucumberを使用すると、次のようなテストを作成できます。

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

この Swingerビデオデモをご覧ください実行中。

Selenium RC があり、WebベースのUIのテストを自動化します。アクションを記録して再生します。 UIとのやり取りを引き続き行う必要があるため、これはカバレッジに役立ちませんが、自動ビルドに使用できます。

テストはアート形式です。ロジックをできるだけGUIから削除する必要があることに同意します。その後、ユニットテストに集中できます。他のテストと同様に、テストはリスクを減らすことです。常にすべてをテストする必要はありませんが、多くの場合、さまざまな分野でさまざまなテストを分割することが最善です。

もう1つの質問は、UIレイヤーで実際にテストしようとしていることです。 UIテストは、作成、保守に時間がかかり、最も脆弱であるため、最も高価なテストです。線を引く前に座標が正しいことを知るためにロジックをテストする場合、具体的に何をテストしますか?赤い線が描かれたグラフをテストする場合。あらかじめ決められた座標を設定して、特定のピクセルが赤かどうかをテストできますか?上記のビットマップ比較が機能するように、SeleniumはGUIをオーバーテストするのではなく、UIの作成に役立つロジックをテストし、UIのどの部分が壊れているか疑わしい部分に焦点を合わせて、いくつかのテストに焦点を当てることに焦点を当てます

JFCUnit を使用してGUIをテストできますが、グラフィックスはより困難な場合があります。何度かGUIのスナップショットを撮り、以前のバージョンと自動的に比較しました。これは実際のテストを提供するものではありませんが、自動ビルドが期待される出力の生成に失敗した場合は警告します。

私があなたの質問から集めたのは、GUIの動作を詳細にテストする自動化された方法を探しているということです。あなたが与える例は、曲線が実際に正しく描画されるかどうかをテストすることです。

ユニットテストフレームワークは自動化されたテストを行う方法を提供しますが、実行したいテストの種類は、GUIツールキット/ライブラリのクラスなど、多数のクラスの正しい動作を検証する複雑な統合テストだと思います、これはテストしたくないはずです。

オプションは、使用するプラットフォーム/ツールキット/フレームワークに大きく依存します。たとえば、GUIフレームワークとしてQtを使用するアプリケーションは、テストを自動化するためにSquishを使用できます。テストの結果を1回検証すると、その後自動的に実行されるテストが検証結果と結果を比較します。

Swing&の

ウィンドウリッカー Ajax

私が知っていることから、これは非常に複雑で、実際に言語に依存します-多くの言語にはGUIをテストする独自の方法がありますが、GUIをテストする必要がある場合(モデル/ GUIの相互作用とは対照的に)、多くの場合、実際のユーザーがボタンをクリックするのをシミュレートする必要があります。たとえば、Eclipseで使用されるSWTフレームワークは、 SWTBot JFCUnit については既に言及しましたが、MozillaにはXULでこれをシミュレートする独自の方法があります(ブログで読んだものから、テストは非常に脆いようです)。

スクリーンショットを撮り、ピクセル完璧なレンダリングをテストしなければならない場合があります(Mozillaはこれを正しくレンダリングされたページをチェックするために行うと思います)-これにはより長いセットアップが必要ですが、グラフに必要なものかもしれません。そのように、コードを更新してテストが中断した場合、失敗が実際であるかどうか手動で画像を確認するか、グラフのレンダリングコードを改善して、きれいなグラフを生成し、スクリーンショットを更新する必要があります。

Swingを使用している場合、GUIの操作には FEST-Swing が便利です。アサーションのテスト。 "ボタンAをクリックするとダイアログBが表示されるはずです" または"ドロップダウンからオプション2を選択すると、すべてのチェックボックスをテストすることが非常に簡単になります選択解除されるはずです。

言及したグラフのシナリオは、テストするのがそれほど簡単ではありません。 GUIコンポーネントを作成して表示するだけで(そして、おそらくFESTでそれらを駆動するだけで)、GUIコンポーネントのコードカバレッジを取得するのは非常に簡単です。ただし、意味のあるアサーションを作成するのは難しい部分です(そして、意味のあるアサーションのないコードカバレッジは、自己欺inの練習です)。グラフが上下逆に描画されたり、小さすぎたりしないことをどのようにテストしますか?

GUIの一部の側面は自動化された単体テストでは効果的にテストできないことと、他の方法でテストする必要があることを受け入れる必要があると思います。

GUIライブラリをテストするのはあなたの仕事ではありません。そのため、実際に画面に描画されているものをチェックし、代わりにウィジェットのプロパティをチェックする責任を回避して、描画されたものを正確に表すライブラリを信頼することができます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top