今日の役に立たない一言 － Today’s Trifle! －

古い記事ではさまざまなテーマを書いていますが、2007年以降はプログラミング関連の話がほとんどです。

GUI のテスト

Java XP

あがたさんからのリクエストに応える。
経験から言わせてもらうと、GUI のテストはなるべく多くの人の目で確認してもらうのが最善策だ。理由はいくつかある。
第一の理由は、テストを作るのが大変だということ。JFCUnit のように GUI のテストを支援してくれるツールもある。java.awt.Robot を利用する方法もある。しかし、いずれにしても GUI のテストを書くのには、GUI 以外の部分と比べると何倍も労力が必要なのでとっかかりにくいのだ。
第二の理由として、GUI は非常に変化しやすいという点があげられる。GUI は文字通りユーザとのインタフェースとなる部分なので、見た人のちょっとした印象やアイディアで変更されることが非常に多い。そうなると、労力をかけて書いたテストは水の泡だ。
第三の理由。自動テストは決して GUI を見ないこと。GUI に対する要求の最も重要な点は、必要なことをきちんと表示することだ。でも以下のような GUI のテストとして最も重要な点は、自動テストで確認することは難しいし、自動テストに書いた内容と人間の判断は異なる結果となることが多い。

  • GUI の全体的な統一感や一貫性はあるか
  • 誰が見ても分かりやすい構成になっているか
  • 文言は簡潔かつ十分に意図を伝えているか
  • 文字列のための領域が足りているかどうか
  • 文字列のフォントが不適切なために読みにくい、または読めない状態かどうか
  • コンポーネントの間隔は広すぎないか、狭すぎないか

こういうのは設計のときにやるべきだという話もあるかもしれないが、普通はここまで詳細な設計はしない。その結果、主観的な判断で作られる。統一感や一貫性を持たせることは、少人数のプロジェクトでも難しい。
それに、プログラムとして動作するのを見ると違う印象をもつことが多い。その結果、仕様(というほど厳密なものは存在してない)がころころと変わることになる。仕様が変わるということは、古い仕様のために作ったテストは意味がなくなるので捨てなければならないし、新しいテストを作るために再び多大な労力が必要となる。
そういう意味からすると、GUI の自動テストを作ることは短期リリースには適していない。
きっと多くの人の目で見ることが最善のテストなんだと思う。
もう少し追加すると、製品を一旦リリースした後、仕様が安定している部分については互換性確認のためのテストを作っるのがいいと思う。(でも、作ってからの時間が長いほどテストターゲットの振る舞いを覚えてないので、テストを書くのは大変だったりする)