FEST-Swingを利用する(8) 視覚の威力
今回は総集編、回想回です…
過去FEST-Swingに関して記述したエントリを以下に示します。
- FESTを使用してJava GUI (Swing)のテストを実行してみる
- FEST-Swingの紹介。FEST-Swingの機能概要を、簡単なサンプルをもとにして実行してみます。
- NetBeansでFEST-Swingを利用する その1 インストール
- 実際にFEST-Swingを利用する場合の、NetBeansでの設定方法。
- 現在の最新とはバージョンが異なりますが、流れは変わりません。
- NetBeansでFEST-Swingを利用する その2 JavaDoc作成
- FEST-Swingから少し外れますが、NetBeansだとソースからJavaDoc作るのが簡単ですよ、というエントリ。
- NetBeansでFEST-Swingを利用する その3 JUnitテストケース作成
- 実際のプロダクトに対してJUnitテストケースを作成し、実行してみます。
- NetBeansでFEST-Swingを利用する その4 テストケースの更新
- テストファーストでプロダクトの仕様変更を行う例。
- FEST-Swingを利用する(5) EDTで発生した例外をJUnitで検知する
- GUIに対してJUnitを適用する場合に問題となる点を解説します。
- FEST-Swing特有の問題ではなく、本質的にはマルチスレッドへJUnitを適用する場合全般に言えることだと思います。
- FEST-Swingを利用する(6) 非EDTでのSwingアクセスを検証する
- Swingスレッドポリシーに違反するコーディングを検知する方法の説明です。
- FEST-Swingを利用する(7) EDTで発生した例外をJUnitで検知するの追補
- (5)で説明した機能が新バージョンで取り込まれていたので、追補として紹介します。
また、上記エントリ中の参考リンクの他、以下のサイトでも日本語でFEST-Swingについて解説されています。
- Swing コードをデバッグし、テストする – IBM developerWorks
- FEST-Swingの作者、Alex Ruiz氏の記事です。
- FEST-SwingでFestival! – アプレッソ開発チームのブログ
これら2エントリでは、冒頭でGUIテスティング自動化の必要性について示されています。これに補足して、私のGUIテスティング自動化のモチベーションは
- GUIが嫌いだ
ということにも起因します。
GUIテストを実施するに当たって、入力を人間が手作業で行うと、必然的に出力の取得も人間が行う必要があり、結果として入出力データの妥当性確認も手作業になります。テスト入出力データ(いわゆる”エビデンス”)の管理も煩雑化し、本当にテストできているのかどうかが曖昧になってしまいます。テスト作業にしても、Excelから拾った似たようなデータを同じ入力欄に入力し同じボタンを押して…と、全く面白みのない単純作業です。これが、ソフトウェアの変更が必要になる度に重なっていきます。
具体例を挙げます。下の動画はさきゅばすの画面で入力した値が正しくコンフィグに保存されるかどうかのテスト(の一部)をFEST-Swingで実行したものです。
小規模ソフトウェアのほんの一機能をテストするためだけでもこれだけの操作が必要です。業務システムでは何回のマウスクリックやタイピング、何種類のファイルの確認が必要になることでしょうか。
GUIテスティングの自動化が達成できれば、上記のようなソフトウェア開発に取って本質的でないコスト(私に言わせれば”不本意な状況”)を改善することができます。
テストの入力データはJUnitで実行するのと変わらず、バージョン管理システムでソフトウェア本体と同期して管理することができます。出力データはすぐにテストを実行し取得することができます。出力値だけでなくテスト実行手順すらエビデンスとして保存できます。
また、テストの作成と実行作業が単調ではなくなります。動画を見てみてどうだったでしょうか。自動で画面が操作される様子を見るだけでも興味がわいてこないでしょうか。FEST-Swingによるテストは、下記引用にあるJUnitのグリーンバーに相当する威力があると考えています。
不思議なもので、グリーンバーが表示されるととてもうれしい気分になり、いつの間にかゲーム感覚でグリーンバーを取得しようと必死になってしまいます。そういった状況に深くはまってしまう症状をテスト熱中症と呼ぶのですが、実際にテストにはまってしまう人の気持ちが分からないではありません。グリーンバーの威力は絶大です。
テストファーストによるソフトウェア開発の衝撃（後篇） – IBM developerWorks
次回、第6回で”次回説明する”と書いてそのままになっていたSwingのスレッドアクセスバイオレーションの話も残っているのですが、適当に作ったさきゅばすの拡張部分が結構バグっていたことが判明してしまった(参考)ので、これを題材に、モックを利用したテストケースの作成を行っていきたいと考えています。
« さきゅばすのNicoBrowser拡張 1.4.2 アクセス先URL変更(暫定)対応 | トップページ | NicoBrowser ver.0.6.1 Java5動作不具合対応 »
この記事へのコメントは終了しました。
« さきゅばすのNicoBrowser拡張 1.4.2 アクセス先URL変更(暫定)対応 | トップページ | NicoBrowser ver.0.6.1 Java5動作不具合対応 »
コメント