Be Agile!シリーズ「バグがないプログラムの作り方」

[excite-imp]
この日曜に買って、そのまま危うく積み本になりそうだった「バグがないプログラムの作り方」という本を引っ張り出してきて読んだ。自分は風呂に入っているときに本を読まねばならない病なので、それならせめて身になりそうな本をと考え、買ってきていたのだ。
まだ、一章すら全て読んでいないという状況なので、軽い感想などを。
自分はガ根性系業務プログラマ、別名デジタルドカタなわけで、現場ではテストユニットなど一切使わずに勘にまかせたテストケース表と力技のデータ入力でテストを行っている。
しかし、仕事の合間に読んでいるPG系のblogなんかで、よくエクストリームプログラミングなんかが紹介してあって、バグの無い世界とデグレードチェックの泥沼に溺れない生活を、常々うらやましいと感じているのである。
ただ、現状では既存の膨大な量のコードに全部テストコードを付ける工数もなく、細かいテストコードをつけて顧客に不審がられることも、上司が許しはしないという状況だ。
仕方なく、細々とテスト時のデータベース状態をエクスポートなどして、テストケース表と共に保存するという小賢しい方法を用いている。だが、所詮は代用作。私が本当に求めるのは自動テストなのである。
この状況をなんとか打開策できないかと、この本を買ってきたわけである。
ページをめくって、「推薦のことば」だとか「監修のことば」だとかを適当に読み流し、第一章のトビラを開ける。なんか小説もどきが載っていた。しかも、テストケース万歳な内容だ。ちょっと引用してみよう。

「なんと、バグがなかったんだよ」
「えぇ!?」
「何よりもテスト駆動開発のおかげだよ」

……どうだろうか。即座に、会話してる二人の名前を脳内で「ボブ」、「スティーブ」と名づけて読んでしまいそうな文章である。アメリカナイズされた怪しげな深夜番組のノリだ。
一瞬にしてこの本の有効性に疑問が沸いてくる。
おそるおそる読み進んでいくと、ふざけたコントはともかく、それなりにマトモな内容そうなので一安心した。
暗雲立ち込める開発状況に光を。とまでは言わないが、バグの数パーセントも減ってくれると嬉しいものだ。
ただ、前にも書いたが自分の開発してる環境はVBなので、自動テストの環境を組むのが少々つらい。
リフレクションが無いと、外部からクラス内のプライベートメソッドがテストできない。機能ごとの細かいテストが身上であるテスト駆動式開発で、これは致命的である。まあそれを言えば、少し老いた感はあるものの言語の大御所であるC++もリフレクションが無いので、なんとかなる気がしないでもないが。
しかしそれで無理矢理安心したとしても、さらに次の試練が待ち受けている。
VB用のテストユニットであるところのVBUnitだが、これが既に過去の遺産となっているのだ。
VB使いには安息の日々は無いのか。
ネットで調べる限りずいぶん昔の資料がちょこちょこ出てくるぐらいで、JUnitやCUnitなんかの賑やかさと比べると、まるで廃墟である。
自分的には、リフレクションが無いという理由から、テストコードと実装コードの分離をある程度捨てて、各クラスのメソッドとしてテストケースを書くという手法を考えている。
あと、過去にちょっと自分流テスト駆動開発をしたときに気づいたのだが、ものぐさな私はテスト実行をするのがメンドイと感じてしまうのである。その原因はを考えてみるに、テスト→実装サイクルは、集中力がテストと実装の間でぶった切られるという悪面も持っているんじゃないかと思う。
もしかすると、慣れれば集中を維持したままでサイクルを進められるようになるのかもしれないが、テンションが上がらないというのは、なかなかキツイ。
とりあえずは、まだこの本には手をつけたばかりという状況だし、ソースは勝手に弄っていい状況じゃないし(それでも勝手に弄るのが効果的という意見もあるが)、アジャイル開発への道は遠いと感じる今日この頃である。