ユニットテストとか

仕事で、数年前に自分が書いたソースを移植することになった。
ソースコードをみて、軽くめまいがした。jdk1.3だ。
とはいえ、junitで書かれたテストコードも見つけて少し希望が見えた。
確かに、テストコードがあると、何をしているのか、外観が掴みやすくていいと、思った。本人が存在を忘れているようなコードだったから、コメントよりも「こうなることを意図している」と書いてあるテストコードの存在がありがたかった。
とはいえ、見慣れてくると違和感も感じるもので
・何でこのメソッドがpublicなのだろう→そうしないとテストできないから
・シングルトンの中身をgetterする謎のメソッドが→そうしないとテストできない
という、自分でも見ていて目を覆いたくなるような、テスト原理主義というか、テストのための設計のオカシさが目についた。
これも不思議なもので、テストコードを先に読んでから、本体を読むと違和感を感じない。なぜなら、テストコードを読んでいる時は「漏れなくテストできている」ことに安心感を抱いていたようだ。
とりあえず、変に見えるかもしれないが、このコードは正しい。なぜならテストに通るからだ。まぁ、外部からライブラリとして使われる予定も無いコードだった（というのを顧客に確認した）ので、publicで見えても、今のところ使用上の問題は無いだろう。ということになった。


さて、JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) を読んで今風のjunit4の書き方を勉強してみる。
いろいろと、目からウロコが落ちる思いがした。
とはいえ、シングルトンには注意せよ、とか、あって、記述があるだけ丁寧だと思うが、求めている答えではないように思った。（別にこの本が悪い訳ではない、本当に「注意せよ」としか言いようが無いのだろう）
「可視性vs中身を開いてテストする」の戦いは続くのだ。


と、思っていたところに、
TDDは死んだ。テスティングよ栄えよ。 by DHH
を見つけて読んだ。妙に得心が行き、胸のつかえが取れた思いがした。
ポイントはテスト自体を否定していないところだろうか。