Index: [Article Count Order] [Thread]

Date:  Tue, 3 Oct 2006 22:20:31 +0900
From:  ushio-txa@....jp
Subject:  [XP-jp:05276] テスト方式レビュー大会
To:  extremeprogramming-jp@....jp
Message-Id:  <20061003222031ushio-txa@....com>
X-Mail-Count: 05276

TO 皆様

牛尾です。

久々に技術ネタを。

先日XP祭り関西で講演を実施しました。多くの皆様にご来場いただきありがとうござい
ました。

その時に公開したPPTとソースコードが下記のURLにあります。
(NEVER NEVER NEVER SURRENDERのセッションの講演資料とサンプルソースです。)

http://xpmaturi-kansai.org/modules/mydownloads/

そのソースを使って、テストしにくい部分のテスト方式のレビュー大会をこのMLでしてみ
ませんか?

 元々この講演のゴールは「初心者や始めたばかりの方が講演を見てくれた人がアジャイ
ルやテスト駆動をやりたくなる」というイメージに設定していました。

 そして、テスト駆動とかを技術的に阻害することを考えたときに、

 1.本だけだとイメージがわいてない人が多い。
 2.本に掲載されるのは単一のクラスの例だが、本物のアプリケーションは複数のクラ
   スが絡み合っているため、どうテストを書くのかわからない。
 3.テストが書きにくいケースが多くて書くのを諦める。

 という感じかなと思っていました。ですので講演では1.をデモして、2.も一部デモ
講演時間が30分(当日は延長してくれて40分になりましたが)なので、本物のアプリ
とまではいかないですが、クラスがある程度沢山でてきて、本物のアプリで遭遇するテス
トが難しいケースを解決している例をステップバイステップでPPTに書いていて、ソー
スも、ステップバイステップで、バージョンアップさせていってるのをサーバーに載せて
います。

 このソースを書き終わって、講演後に公開するときにふと不安な自分に出会いました。

 「このやり方であってるやろか?もっといい方法はないだろうか?」

 私の方法はあくまで自分流の現場でやってきた方法なので、あまりCOOLではないかもし
れません。そこで、たまたまこの講演をやる前に数人のアジャイラーに取り囲まれる機会
があったので、「こういう場合、どうやってテストしてます?」とか言う議論をしたので
すが、これが結構おもろい。いろんな発見があったり、安心するところもあったり。

 結局現場では、みんな独学でやってると思いますが、アジャイラーに囲まれて普段議論
ができない人が多いと思います。ですので、コードを皆さんに公開するのはめちゃめちゃ
恥ずかしいですが、このショボいコードと解決策をたたき台にしてレビュー大会してみま
せんか?
 このMLで「この部分は俺やったらこうする」とか「こっちの方がこういう理由でCOOLだ
」とか「わしはそもそもこういう設計にする」とか理由と解決策をつけてこのコードにい
ちゃもんをつけるなり、なんでこうしてるん?という議論をしたりするのは楽しいかもし
れません。

 アプリケーションはTOMCATにファイルを置いてそれをダウンロードする仕組みです。
TOMCATにはBASIC認証がかかっていますし、サーバーにアクセスしますので、サーバを立ち
上げとかないとテストできないのはイマイチです。
 またログは当然いろいろなクラスから使われますが、今回の仕様では、ログのレベルは
設定ファイルから取得することになります…などなどいろいろな仕掛けをしています。

 また、クラスはアーキテクチャ系のクラスからユーティリティ系、ドメイン系など
バリエーションにとんだものを用意しているので、本物みたいなエラーチェックの厳密さ
などはありませんが、それなりの構造をしています。

 そんなわけで、われこそはMr.TDDという人も、そうでない人も、わたしのしょぼ
いコードを肴に「よりよいテストの書き方」を議論してみませんか?

 私はとてもしょぼいのでもっとちゃんとかけるようになりたいと思っています。

ちなみにソースの構成は下記のようになっています。詳しい?説明は講演資料においています。

setup  step06,step07で必要なtomcatの設定です。
step00 私としゃけが舞台で実演したクラス。これは初心者へのわかりやすさを重視しています。
step01 ログのテストの例です。このログは標準出力しますが、それをテストします。
step02 ログのクラスを設定ファイルから取得するようにしたが、そのテストを実施。
step03 時刻つきログの作成。現在時はテストできない(か意味がない)
step04 ログのテスト用設定ファイルの整理方法(Mockで騙さないのをテストしたいケース)
step05 他のクラス(Messageクラス)でログを使用するが、ログの出力を含めてMessageクラス
    をテストしたいケース。ただし、LogはMockが挟み込みにくいコーディングになる。
    しかも、MessageクラスのテストのためにLogの設定ファイルを用意しないといけない
    のは面倒くさい。
step06 サーバからファイルを取得するアプリケーション例。この例はテストをしにくい
    構造になっている例
step07 step06と全く同じ機能のアプリケーションだが、テストしやすい構造にしてテストを
    している。

以上です。