Skip to content.

Sections
Personal tools
You are here: Home » コミュニティ » masarl memorial » masarl.cocolog-nifty.com » main » 2004 » 02 » Cotton Bolls: テストファーストの判断基準

Cotton Bolls: テストファーストの判断基準

Document Actions

« アスペクト指向のデザインパターン的解釈 | トップページ | コンテンツ言語Curl »

2004.02.01

テストファーストの判断基準

テストファーストが難しい分野にGUIプログラミングがある.この分野には,JUnitの拡張としてJFCUnitやAbbotなどのテスティングフレームワークが用意されているようだ.

数年前にGUI部品を提供するライブラリの保守・機能追加でJFCUnitを使っていたことがある.キー入力やマウス入力をJFCUnitやjava.awt.Robotを使って書くのは難しかったが,おおむねうまくいったように思う.特によかったのは,Java本体のバージョンアップによるバグが一瞬にして見つかったことだ.以前のJavaならテストがすべて通るのに,Javaを新しくするだけでテストが失敗してしまう.すぐJava本体のコードを調べると,フォーカス周りの実装ががらっと変わっている.そこに依存していたコードが原因でライブラリがバグっていたのだ.

その後GUI部品の仕事が終わり,Swingを使ったGUIアプリの仕事になった.このときにはすでにJFCUnitに慣れていたし,ある程度成功を収めていたからGUI部分もテストファーストでやっていけるだろうと思っていた.納期は厳しかったが,ペアプロでJFCUnitの使い方を教えていけばなんとかなるだろうと考えたし,ノウハウがたまれば「JUnit実践講座」に記事を追加してもいいだろうとさえ考えていた.――しかし,それがかなり甘い考えだったことがわかった.

始まってから1ヶ月経っても開発がうまく軌道に乗らないのだ.XPは最初のイテレーションが一番難しい.でも数回イテレーションをまわせば開発スピードが加速度的によくなってくる.それが普通だ.なかなかストーリーが終わらないのはどこか間違ってる.その原因がJFCUnitを使うことのように思えてきた.JFCUnitには,次のような問題がある.

1) テストケースを書くのが難しい

テストファーストでテストを書こうと思っても,テストコードが複雑になりすぎてテストを書くだけで力がつきてしまう.またJFCUnitのテストは単体テストというより受け入れテストに近いので,「テストコードがクラスの仕様書」というテストファーストのメリットを享受しにくい.

2) テストを自動化してもバグが見つかりにくい

(1)と関連するが,JUnitで自動化するといくつかの簡単なパターンのテストで手一杯になってしまう.テストは通っても実際に手で行うといろいろバグが見つかる,ということがよくあった.

3) 同期をとるのが難しい

JFCUnitにはGUIの同期をとるためにawtSleepというメソッドがある.実際にはうまく同期がとれなかった.まだ画面の準備ができてないのにassertメソッドが先に動き誤った結果を評価してしまう.本当はテストが通っているのに失敗する,ということが頻繁に起こってしまった(これは,自分の技術力不足のせいなのかもしれない).

GUIアプリではなくGUI部品の開発でうまくいったのは操作が限定されていたからだろう.GUI部品で複雑なユーザ操作をシュミレートする必要は無い.単にボタンをクリックするだとか,キー入力でフォーカスを移動するだとかその程度だ.メニューを選択し,ダイアログを出して,「追加」ボタンを押してキー入力し,「OK」ボタンを押してダイアログを閉じ,効果を確認する…なんていう複雑な操作は必要ない.こんなことをテストファーストでコードを起こすなんてとんでもない話だ.

ここまで考えた後でメンバーに方針を伝えた.すなわち,「基本的にGUIではテストコードを書くな」と(正確には,「5分考えてダメだったら」という条件つきだったが).メンバー間で「GUIテストは書かない」という方針が行き渡ると開発スピードがどんどん上がっていき,XP本来のドライブ感が取り戻せた.もちろん,GUI周りのバグは残ってしまうが,テストコードをばっさり切ってしまうことでXP本来のリズムに乗ることができたのだ.

さて,ここまでGUI開発でのテストファースト成功例,失敗例を紹介した.一言でいうならこの違いは「リズム感」にあると思う."test a little, code a little"のリズム感だ.失敗した事例はtest a littleで無かった.テストコードを書く負担があまりにも大きく,実装コードを書く余裕がなくなっていたのだ.

テストファーストするかどうか考えるときは,このリズム感が判定基準になると思う.テストファーストすることでリズムが狂ってしまうのなら,それは間違っている.大事なのは,テストファーストを守ることではなくリズムに乗ることだ.テストファーストより,リズムの方が大事だということを認識しておく必要がある.テストが負担になっているのなら,それを軽減するフレームワークが提供できないかも考えておかなければならない.

|

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/152307

この記事へのトラックバック一覧です: テストファーストの判断基準:

» GUIテストとテストファースト [たまゆら雑記から]
テストファーストの判断基準 GUIのテストは難しい。テストコードを書いてガリガリやっても見つかるバグがわずかだったりします。それよりも適当に画面を操作していけば... 続きを読む

受信: March 6, 2005 11:13 PM

コメント

コメントを書く