XPの提唱者の一人であり、TDDやJUnit自体(リンク)の開発者であるKent Beck氏(リンク)は、デバッガの代わりに単体テストを用いて、JUnitの新しい機能であるJUnitMaxの不具合の調査を行うことについて話をしている。彼は現在JUnit(リンク) の開発をリードしているDavid Saff氏(リンク)によって示された方法について説明している。その方法では、不具合の原因に対応する極めて簡潔なテストがあるまで、ハイレベルの単体テストが再帰的にインライン展開される。
Beck氏は彼が「Saff Squeeze(リンク)」と名付けた方法を、アメリカンフットボールの「サンドイッチ」として知られるオカレンスにたとえて紹介している。サンドイッチとは、ボールを持っている人に対して２人同時にぶつかるもので、１人は「高いところ」（肩の近く）に、もう１人は「低いところ」（腰や足）に当たる。彼は「Saff Squeeze」が、失敗したハイレベルの単体テスト（「高いタックル」）を、問題のコードを直接特定するテストがあるまで（すなわち、不具合が「タックル」されるまで）、もっともっと限定された単体テスト（「低いタックル」）に再帰的に置換することで対処するという点において、これによく似ていると説明している。
Beck氏によると、この方法の説明の概要は次の通りである。
Saff Squeezeは、私はこの方法をそう呼んでいるのですが、失敗したテストを、不具合を見失わずにはそれ以上インライン化できなくなるまで、それを革新的にインライン化していくことで機能します。そのサイクルは次のようになります。
- テストの中で、機能していないメソッドをインライン化する。
- （失敗した）アサーションを、既存のアサーションよりも前に置く。
- テストの中で関係なくなった部分を取り除く。
- 繰り返す。
短い記事の中でBeck氏は、みなさんのためにこのプロセスを実践し、テストコードを様々なステップで見せ、最後にその極みである、実際の不具合に注目させる「squeeze」されたテストを示している。
彼はこのアプローチを、もっと従来型のデバッガを使用してウォークスルーするアプローチと比較し、以下のような結論を下している。
この２つのプロセスの１つの重要な違いは、デバッグを行ったあとにはどこに不具合があったのかがわかりましたが、squeezをしたあとには、さらにその不具合のための最小の単体テストもあることです。その簡潔なテストは、このプロセスの役に立つ副産物です。
Beck氏はこの方法を、新しいコードのためのTDD開発サイクルへの追加や変更ではなく、むしろ不具合解決に利用するツールであると考えていることを明らかにしている。
この方法は、不具合を特定し修正するための、統制のとれたアプローチの主要部として機能するでしょう。
- システムレベルのテストで不具合を再現する。
- Squeezeを行う。
- どちらのテストも動くようにする。
- 不具合の根本的な原因を分析して除去する。
この記事(リンク)に目を通し、実際の例ではどのように見えるかや、この技術の適用性についてのBeck氏の意見の詳細はもちろん、Eclipseのインライン化機能についての不満も読んでいただきたい。
あなたはこの方法がデバッガから解放される助けとなると考えるだろうか？このアプローチにはリスクがあると思うだろうか？同じようなことをしたことがあったり、あるいはまったく異なるアプローチをしたことがあるだろうか？ここの議論に追加してほしい。
原文はこちらです：http://www.infoq.com/news/2008/11/beck-saff-squeeze