テストファーストの自分なりの方法が確立できてきた。
- 本コードのメソッドとフィールドを書く。しかし中身はなし。戻り値が必要な物はダミーを記述する。
- そのコードをテストするためのテストクラスを作成し、正常パターンのシナリオを作る。シナリオの実装はまさーるさんのhttp://member.nifty.ne.jp/masarl/article/junit/scenario-based-testcase.htmlというシナリオベースドテスティングを使用する。
- 初回はわざと失敗することを確認。
- 本コードの中身を実装する。
- 異常ケースのテストと、実装することにより新たに発見されたテストコードを記述する。
- もし、１回目で成功した場合は「期待する値」を変更して失敗するかどうか確認。成功しなかった場合は本コードを修正して確認。
ビジネスアプリケーションをオブジェクト指向で本格的に記述することが初めてなので、試行錯誤することが多い。だからこんな状態ではjunitは非常に威力を発揮する。
作っていく間に修正したい箇所ができてくるけれども、このテストを作っておくと修正することが本当に簡単になる。これはたしかに手放せない。
まさーるさんのシナリオベースドテスティングについては、はじめいろいろ戸惑うことも多かった。シナリオへの引数や戻り値を引数という形ではなくクラスフィールドを使うところなどはなかなか理解できなかった。しかし、テストケースとしてチェックをする場合はいろんな情報が必要であって、やはり大域変数のような形にしておかないと満足なチェックができない。
とはいえ、いまだにまさーるさんに逆らっているのは以下のところ。
ここでは，実装コードとテストコードのコメントの書き方について解説します．まず，最初に言っておきたいのは 実装コードにはコメントを書くべきではない． ということです．できることなら javadoc も書かないほうがよいのです．コメントを書けば，リファクタリングの度にコメントを更新することになります．これは小さいことに見えて，後から大きな問題になりえます．リファクタリングは，なにも小規模なものだけではありません．コード全体に関わる大規模なリファクタリングもあるし，開発していけば，必ずそういうものに遭遇するでしょう．XP では実装コードはかなり流動的です．常に変わるものです．コメントを書けば，リファクタリングするパワーが半減します．コメントを書く余力があるなら，そのパワーをテストコードに使ってください．
javadocは使ってます。でも確かに面倒だし、リファクタリングのじゃまになる。また、リファクタリングをしているうちに嘘の内容になるのが一番怖い。
また、引数違いの項目や単に別のクラスに委譲しているだけのような場合に、コメントを二重に記述するのがすごく嫌。@seeは参照先を示すだけで、コメントを置き換えてくれるわけではない。
でも、先生に見せるときは絶対に効果があることは分かっているから、あえてがんばってみようかなと思う。
うやうやしくだしてやろう。
