渋日記@shibu.jp

TDD/BDDは不完全な単体テストを誘導するという記事が出ています。要点としては、TDD/BDDは、特定のケースの検証をしているにすぎず、アプリケーション内部で発生しうる、すべてのケースの検証をしているわけじゃない、ということです。まぁ、考えてみれば当たり前なんですけどね。

カバレッジだけを考えても、C0(命令網羅)、C1(分岐網羅)、C2(条件網羅)と３段階あります。現実的に考えて、アプリケーション全体の条件網羅を行うのは不可能です。if文が32個あれば、2の32乗です。42億通りです。実際は、ネストしたりいろいろあって、完全にすべてのif文が独立、ということはないので、これよりも遙かに少なくなりますけどね。完璧なテストはムリですよね。

実際はなるべく少ない手数で効率よくテストをすることを考える必要があります。まずは各部品が正常に動かないと全体がうまく動きようがありません。TDD/BDDによって、そこの部分は達成されます。TDD/BDDでは、単なる単体テストと違い、関連するオブジェクトも一緒にテストします。モックを使うこともありますけどね。その上で、現実的な使い方を受け入れテストでテストしていきます。これが一番効率のいいテスト方法かな、と思います。

もちろん、インタフェース外部からの使われ方をなるべく網羅するようなにテストケースを充実する、というのは一定の効果があります。あとは手間と効果のトレードオフですね。この場合、ネジ、クギにあたるような部品のプログラムであればかなりやりやすいです。でも、フレームワークの中にべったりくっついているコードは、「動作検証」程度のテストはできても、「これで大丈夫！」と言えるようなテストは難しいです。

PySpecの場合は、自分のテストを自分自身のフレームワークを使って書いています。部分だけ取り出してうまく動いても、さて、それを使ってテストしてみようか、と思って使ってみると、思ったよりも使いにくかったりして、APIを書き換えることもあります。PySpecの場合はAPIそのものがユーザインタフェースですから、そこにこだわる必要がある、という事情もありますけどね。

というわけで、TDD/BDDだけで完璧だなんて思うのは間違いです。テストもトレードオフです。