テストの為に、ソースコードは曲げるべき？

Javaなんかだと後からアスペクト指向的にログ出力したいなんて思うと、
そのクラスに対応したインターフェースが必須になってしまいます。
（Java 8で解決されていたらごめんなさい。）

そういうパターンはテスト目的であることが多いのですが、
そのためだけにインターフェースを追加するのは豪華すぎる気がします。

保守性が上がるという反論が聞こえそうなんですけど、
1クラスのために1インターフェースを作らなければならないのはいびつに感じます。

ある程度クラスのパターンが決まってれば1インターフェース：多クラスになりますが、
1クラスのみに実装された特殊なメソッドの場合…ああ、JUnitを使えばいいのか。

 

でも同様の話題はJUnitでも言える気がします。

（TestNGを使えというツッコミは当然ありますが、）
privateはテストしにくいのでprotectedにするかもしれません。

ほぼ一択でしかないメンバ変数で持っていたインスタンスを、
コンストラクタによるDIに変えなければならないかもしれません。

 

まあきれいに書ければあんまり多くは無いのですけど、
テスト目的でソースコードを変更することってあるわけです。

そしてその変更は、
ソースコードを複雑にしてしまうことがあるのです。

テストの為に複雑さを許容するというのは、
何か間違っている気がします。

ちょっと前の記事では動的型付け言語のテストの難しさを紹介しましたが、
こっちは静的型付け言語のテストの難しさです。

テスト用にこねくり回したいところが硬くてしょうがないのです。

 

テストの時だけ柔らかくなってくれはしませんかねぇ？

こねこね♪こねこね♪