コード内の計算は十分にテストされていますが、GUI コードが非常に多いため、全体的なコード カバレッジは思ったよりも低くなっています。GUI コードの単体テストに関するガイドラインはありますか? それは理にかなっていますか?
たとえば、私のアプリにはグラフがあります。グラフのテストを自動化する方法がわかりません。グラフが正しいかどうかを確認するには、人間の目、AFAIKが必要です。
(私は Java Swing を使用しています)
コード内の計算は十分にテストされていますが、GUI コードが非常に多いため、全体的なコード カバレッジは思ったよりも低くなっています。GUI コードの単体テストに関するガイドラインはありますか? それは理にかなっていますか?
たとえば、私のアプリにはグラフがあります。グラフのテストを自動化する方法がわかりません。グラフが正しいかどうかを確認するには、人間の目、AFAIKが必要です。
(私は Java Swing を使用しています)
MVP や MVC などの設計では、通常、実際の GUI からできるだけ多くのロジックを抽出しようとします。これに関する非常に人気のある記事の 1 つは、Michael Feathers による「The Humble Dialog Box」です。個人的には、ロジックを UI の外に移動しようとして、さまざまな経験がありました。非常にうまく機能する場合もあれば、必要以上に面倒な場合もあります。多少専門外ですが。
もちろん、答えは MVC を使用して、可能な限り多くのロジックを GUI から移動することです。
そうは言っても、ずっと前に同僚から、SGI が OpenGL を新しいハードウェアに移植していたとき、一連のプリミティブを画面に描画し、フレーム バッファーの MD5 合計を計算する一連の単体テストがあったと聞きました。次に、この値を既知の適切なハッシュ値と比較して、API がピクセル単位で正確かどうかをすばやく判断できます。
UISpec4Jは、Swing ベースの Java アプリケーション用のオープン ソースの機能および/または単体テスト ライブラリです。
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 ビデオ デモを見て、動作を確認してください。
Web ベースの UI のテストを自動化するSelenium RCがあります。アクションを記録して再生します。UI との対話をウォークスルーする必要があるため、これはカバレッジには役立ちませんが、自動ビルドには使用できます。
ここにいくつかのヒントがあります:
GUI なしでテストできるように、GUI からできる限り多くのコード (コントローラーとモデル オブジェクトを含む) を削除するようにしてください。
グラフィックについては、グラフィックを生成するコードに指定する値をテストする必要があります。
テストはアートフォームです。ロジックはできる限り 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を使用している場合、FEST-SwingはGUIの駆動とアサーションのテストに役立ちます。「ボタンAをクリックすると、ダイアログBが表示される」、「ドロップダウンからオプション2を選択すると、すべてのチェックボックスが選択解除される」などのテストが非常に簡単になります。
あなたが言及するグラフシナリオは、テストするのがそれほど簡単ではありません。GUIコンポーネントを作成して表示する(そしておそらくFESTでそれらを駆動する)だけで、GUIコンポーネントのコードカバレッジを取得するのは非常に簡単です。ただし、意味のあるアサーションを作成することは難しい部分です(そして、意味のあるアサーションのないコードカバレッジは自己欺瞞の練習です)。グラフが上下逆に描かれていない、または小さすぎることをどのようにテストしますか?
GUIのいくつかの側面は自動化された単体テストでは効果的にテストできず、他の方法でテストする必要があることを受け入れる必要があると思います。