メモ
以下、なんとなく最近感じているメモ。そのうち真面目にまとめます。
- 試験を効率的に自動化するためなら、美しい設計なぞ端からあきらめる。
- UTは100%の自動化を目指す。そのための設計を行う。
- UTはメソッド単位で試験を行い、自動化する。
- メソッドの種類を次の３種類に分けて設計・実装を行い、自動かもパターン化する。
- 外部接続メソッド
- 自己完結型メソッド
- シーケンスメソッド
- 外部接続メソッド
- 外部接続メソッドは、ファイル・ＤＢ・ネットワークなど、プログラムの外部環境にアクセスするメソッド。
- 入出力が正常に行われるかの試験を、UTで行う。
- なるべくシンプルにして、試験を行わなくて済むようにする。
- 分岐、繰り返しが出てきたら、負け組み。
- 自己完結型メソッド
- 外部のクラスや、環境などにアクセスする必要がないメソッド。
- 可能な限り、ステートレスが望ましい。ステートレスなら、試験は境界値に対する入出力のみの確認で可能。
- ステートレスでない場合は、ステートを確認する手段を用意しておき、試験実施前のステートを入力として扱い、試験実施後のステートを出力として扱う。
- シーケンスメソッド
- 他のクラスへのアクセスや、多量の分岐、ループなどが存在するメソッド
- 試験前は、シーケンスを確認できるスタブを気合で作りこむ
- スタブが管理すべき情報としては、こんな感じ。
- メソッドの呼び出し順序
- 呼び出した際の引数の値および戻り値（例外も含む）
- 試験プログラムでは、スタブの呼び出し順序と、引数の値を全チャックする。
- スタブを作りやすいような構造
- １つのメソッド内の分岐やループは、分岐の爆発を防ぐため、３ネスト以上しない
- 試験項目表はチャンと作る。JUnitで試験する場合、項目番号と、テストメソッドの名前を一致させると楽。
- 試験項目が012である場合、JUnitのメソッド名はtest012にする。
- 試験高目標に必要な項目は、最低次の３つ。
- 試験内容が簡潔に表される試験項目名。
- 前提条件（環境とか入力とか）
- 確認項目（出力値とか出力値とか出力値とか）
- 一度作った試験項目は消さない。変更したい場合でも、新規に項目を起こす。必要なくなったものは、グレーアウトするなり、コメント化するなりして、絶対に消さない。そのうち、役に立つときがある。
- 試験プログラムは、ループ、分岐が入ったら負け組み
- 各オブジェクトには、一致判定のメソッドを準備する
- 【過激】フレームワークでない限り、privateメソッドを使うことは、負け組み。どうせ自分しか使わないメソッドは、逆にprivateにする必要なし。
- 入力値、出力値の生成は、１箇所で行う。そうすれば、入力値、出力値の齟齬によるバグは発生しない。
- 【過激】設計書がチャンとある場合は、クラス名とかにはこだわるな。採番で十分。むしろ、そのほうが、設計書との連携を密にできる。
- クラスの役割を意識して、クラス分割に励む
- UTのステップ数は、本番プログラムのステップ数の３〜５倍ぐらいが密度的にちょうど良い。少なければ、抽象化しすぎか少なすぎ。多ければ、試験のやりすぎ、時間の無駄。
