ユニットテストを減らしつつバグを減らす方法

極力ユニットテストを書かずに品質を確保する方法 - ひがやすを blogを読んで、ちょうど先日同じ話をしていたので。

via Cocoa Code - 1 on Flickr - Photo Sharing!

テストファーストで書かないと、と思いつつも工数や納期に押されて書けずにいる人は多いと思います。プログラマにとってみれば、自分の書いたところにバグはないと信じる気持ちもあるので、あまり気が進まないということもあります。

そこで、書くべき場所と書かない場所を決めてしまうのが大事かな、と。

書かなくても良い場所、というのは「こんなところでバグが起きる訳がない」という場所。例えばフレームワーク側で自動で生成してくれる部分。データベースにデータを保存して、その値を取り出してチェック、なんてバグっていたら話にならないので飛ばす。こういう場所はテストが書きやすいということもあって、最初の頃は頑張って書いたりするのですが、すぐに面倒になってテストを書くこと自体止めてしまう原因になります。

書くべき場所は「分かりづらい仕様の場所＝ワークフロー」。例えば販売管理システムでフラグを立てて、バッチ処理を実行すると、そのデータがこういう条件の場合は会計へ、こういう条件の場合は会計にはいかないといったようなシステムの肝になるような処理です。

10件のデータを投入して、結果が10件でした、なんてことはチェックの優先順位は低くても良いと思います（もちろんチェックした方が良いですが手間が増えて、本来すべき部分がなくなるよりもマシ）。そういう意味ではプラグインやライブラリを活用することで、動作保証の担保を別に預けていければテストすべき部分は減っていくのではないでしょうか。

逆にすべき部分というのは、ワークフローであって肝の部分です。仕様の理解をするためにもまずテストのコードを書いてみて、うまく動くかどうか確認するというのは大事ではないかと思います。