Shibuya.trac 第7回勉強会で発表しました

技術

発表スライドはこちら

Hudson tanabata.trac

私の勤めている会社のようにslideshareとかはてなフォトライフとか見れないんじゃい！っていう方のためにPDFも下記に置きました。ちょっと重いですがw

http://dl.dropbox.com/u/8494587/Hudson-Tanabata.pdf

まず会場を貸していただいた @tomohn さん、会場面でおもに調整していただいた @kanu_ さん、スイーツとか諸々手配していただいたちょびさん、企画していただいた @LightningX さん、司会していただいた@ikikkoさん、Ustしていただいた@nekotankさん、はじめ全てのスタッフ、発表者、また見に来ていただいた皆様に感謝します。ありがとうございました。m( )m

Shibuya.tracというか勉強会自体初参加でしかも発表までやらせていただいてありがとうございます。

プロジェクタの接続テストもしてトップバッターとして発表したのでだいぶ楽でした。残りの発表もビザ食ったりビール飲みながら楽しんで聞けました。

今回iPad+Keynoteの組み合わせで発表しました。ちなみにスライドはiPadではなくMacBookで作りました。Keynoteはほとんどキューブ使いたいがために使いました。またiPadのKeynoteとVGAアダプタはこの発表のために買ったようなものですw　ちなみにiPadでプレゼンしようとするとiPad上ではスライドは小さくてほとんど見れません。プロジェクタを見ながらプレゼンすることになります。

こういった発表自体が新人の時以来な気がするので7年ぶりかな。いちおう練習はしました。持ち時間20分に対して練習では十分余っていたのですが、当日は@ikikkoさんの司会と@LightningXさんの挨拶で場が暖まったことや聞いてくれた人の反応が良かったためか、予定以上にしゃべりすぎました。時間見る余裕無かったけどたぶん30分ぐらいしゃべったと思う。後が押してしまう原因になってすんません。m( )m

発表内容について補足しておくと、今回は新規の案件であったので古いJUnitのテストケースは存在しないです。あとJUnitのテストケース作成とHudson投入の時期はだいたい同じです。

自動テストの粒度は機能レベルが良いと言ったのはその方が書くのもメンテするのも楽だと思うからです。ただしGUIからむものはのぞきます。

ここで言っている機能レベルの自動テストとは、詳細設計書、機能仕様書、テスト仕様書、マニュアルなどからわかる仕様をもとに行うブラックボックステストです。クラスの中身には触れ無い分書きやすくメンテしやすいと考えています。だからJUnitである必要はありません。シェルでもOK。ただJUnitのほうがHudsonで結果集計できる。

もうちょっと具体的に言うと例えばFindBugsのようなEclipseプラグイン形式の静的解析ツールを作っているとします。

ユーザのマウス操作や指摘結果を表示する部分は自動テスト対象外です。

自動テスト対象なのはエンジン部分です。このエンジン部分の仕様は入力がソースファイルで出力が指摘結果のログだとします。

ソースファイルを読み込んでエンジンに処理させて結果を判定するようなシェルスクリプトを書けば自動テスト環境が出来上がります。エンジンに処理させるソースファイルがテストケースになります。

この場合エンジン内部の処理（字句解析、構文解析、意味解析など）は複雑になっているはずですが、その内部処理がわからなくてもテストケースはかけますしメンテも楽です。たいていはテスト失敗=バグでしょう。過去のバグをもとにテストケースを整備すればデグレード防止になります。

JUnitによるクラスレベルの自動テストのメンテが難しいのはテスト失敗がバグなのか仕様変更なのかすぐにはわからないからです。テストの粒度が細かすぎるとメンテしづらいです。ある程度大きい方がメンテしやすいです。ただあまりにもテストの粒度が大きすぎるとテストが失敗したときにどこが問題なのか切り分けにくくなります。バランス重要。テストしやすいアーキテクチャとして依存関係をクラスレベルよりもまずモジュール（jar,war）レベルで考えるほうがいいでしょう。

これでもスローテストの問題は以前としてありますが、正直にいって自動テストの数は少なくてもいいかなと。スモークテストとしてのみ使うという割り切りです。スローテストになるとメンテする気力も失せます。ただメンテしないテストもありだとは思います。

というわけで現時点での僕の感触として回帰テストの意味で自動テストをやるなら、

  • 受託ではなく自社のプロダクト、サービス開発
  • GUIなし
  • 粒度は機能レベル
  • テストケース数は10分ビルドの範囲内におさめる

です。これならコストメリットがあう。

少数精鋭なメンバーだったり、設計技法としてJUnitを使ってクラスレベルの動作確認をしていく場合は話は別です。