テスト駆動開発について考える †
新規で作る場合と、既存のコードがある場合とでわけて考えたほうがよさそうだ。
まずは、新規で作る場合で、テスト駆動の開発について思ったことを書いてみようと思う。
いたくない注射針を作った町工場のおやじさんの本を読んだ。
そこには、こんなふうなことがかいてあったんだ。
図面はどんなにがんばっても、６０点でしかないことが多い。
だから、図面通りつくっても、６０点にしかならないし、結局、ああしたほうがよかった、こうしたほうがよかったって出てくる。
そんなことよりも、即興のジャズのようにだんだん１００点に近づけて行くんだ。
みたいなことが書いてあった。
そういう本を読んだあとに、テスト駆動とはなんぞやという、説明しているサイトをみた。
モックの作成、それに先立つ
インターフェースの発見
テスト駆動のやり方は、６０点の設計書で行きましょうというやり方に近いだろう。
インタフェースだらけの設計ってどうなんだろう †
以前、プログラマーが１００人がかりのプロジェクトに参画していたときの話なんだけれども、
そこでは、とにかくクラスを作るとインタフェースもセットでつくならくちゃならなかったんだ。
インターフェースだらけになると、ビルド時間も増えるし、ビルドのためのメモリもかさむし、ソースコードを解析しようにも、IDEのタグジャンプ機能では、具体的なメソッドまでたどりつけずに、インターフェースの空っぽの定義にたどりついちゃうんだ。
面倒でしかたがなかったよ。
インタフェースを作らなくてもテストはできるんじゃないか †
そもそも、モックオブジェクトがテストに必要っていう考え方がだめなんじゃないだろうか？
メソッドの引数のつくりかたによっては、テストしやすく作れるはずなんだ。
結びつきを疎にするとかって言う人もおおいんだけれども、自分は、グローバル変数の影響を最小限にすればいいんじゃないかと思う。
モックオブジェクトとか、DBの初期設定とかも、自分はグローバルな外部の変数だとおもうんだ。
それの厄介なところは、いらない変数が多いこと。
できれば、少ない変数で処理を把握したい。
むしろ、モックを使わずに、テストできるようにしたいんだ。
状態遷移のあるプログラム †
経験上、状態遷移を含むプログラムは、厄介なことになりがちだ。
テストデータの作りやすさ †
事前のデータを作ることが困難だったりするだろう。こっちのほうが、はるかに大事だったりするんだ。 なぜかというと、 何度も修正して、動作確認、修正して、動作確認ってやるんだけど、動作確認には、不具合が再現する一歩前に条件をすぐにそろえなくてはならないからなんだ。
