Software Engineering RadioというPodcastの、ケント・ベックのインタビュー（以下URL）が面白かったので要点を日本語訳したい、という話がもちあがった。
http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/
平鍋さんがご自身のブログで言い出した話である。
http://blogs.itmedia.co.jp/hiranabe/2010/10/the-history-of.html
平鍋さんの後を@urimaro(id:goh-m)さんが引き受けて、さてその後が続かないようで、「誰か続きをやりませんか？」と平鍋さんがツイッターでつぶやいたのを見て、ちょっと面白そうかも、と思ったわたくしが酔った勢いで「やります」と引き取ってしまったわけですよ。
んで16:40以降を担当したわけだが、うーん、なんとなくはわかるけど細かいところがちょっと… でもまあ良いか、「要点」を訳するんであって逐次訳である必要はない。したがってわからんところはばっさりと（!?）。
というわけで、かなり怪しいところがあるので、これを目にした心ある方は、ぜひとも修正していただけると幸いなのであります。では以下に、16:40から24:05までの訳を。
Martin: 多くの人はいまだに「実際にコードを書く前にテストをするなんて頭おかしいんじゃないの？」と思っていたり、怖がっていたりするんですけど、それについてどう思いますか？
Kent: いったいどんな問題があるのか、興味があるね。で、あなた自身はTDDをやっているの？
Martin: ええ。
Kent: では、そういう人たちに対しては、何と答えている？
Martin: TDDなら持続可能なペースで少しずつ開発を進められて、やらなければいけないことを分割することで考える対象を小さくし、実装しやすくなる、と言ってます。
Kent: うん、まさにぼくもそう感じているよ。
問題は、ソフトウェアテストの社会的地位が低いことだと思う。プログラマはテストを書く必要がないと思われているが、ナンセンスだ。
ぼくの場合、30%〜40%の時間をテストを書くのに費やしている。テストを書いているときも、単にテストを書いているのではなくAPIに関する決定や、分析に関する決定を行っている。そしてテストは、これらの決定を記録するメモでもあるんだ。*1
Martin: 今までに話をした人を説得できたと思いますか？
Kent: よくわからないね。今はもう、説得しようとはしてないから。たぶん10年ぐらいTDDやペアプログラミングの効用について語ってきたけど、今は説得はしてない。常に自分のプラクティスを改善しようとしているんだ。自分が学んだことを共有したいと思っているし、他の人たちが経験から学んだことを聞いて、理解したいと思っている。どれだけの人がTDDをやっているのか数えているわけじゃない。ソフトウェア開発のプラクティスが改善されていっているのなら結構なことだし、ぼくがそれに少しでも影響を与えられているのなら、うれしく思うよ。
で、あなたが聞いているのは、TDDがどれだけ普及しているかということ？製品のコーディングで、一行書くごとにテストをしているのはいまだにごく一部のひとたちだけだと思うよ。
Martin: ふむ。
Kent: 多くの人がテストとその潜在的な価値にふれている。だけどいまだに、「ああ、たくさんのテストをやったよ。だけどもうテストは動かなくなったから取り除いたよ」という人が多い。それを聞くと奇怪な話だと思う。テストが動いているならプログラムも動いているし、テストが動かないならプログラムも動いてない。テストが動かなくなったからといって、そのテストを削除してしまうのは間違っている。
彼らには色んなプレッシャーがかかっているのもわかる。だけど、テストを信頼して、もっと注意を払えば、ソフトウェア開発においてもっと大きな、潜在的な価値を作り出すことができるはずだ。
Martin: 他にも多くのテストに関する哲学があると思うのですが。たとえばビヘイビア駆動開発とか。それについてはどう思います？
Kent: ぼくの考えている大きなピクチャは、とてもポジティブだ。プログラマが積極的に仕事のクオリティについて責任をとることは、それを何と呼ぼうと良いことだ。TDDに関する最初の議論において、ぼくがうまく伝えることができなかったのは、様々なスケールでテスティングをすることの重要性だ。TDDはユニットテストの哲学ではない。ぼくは、どんなスケールにおいても、次のステップに進もうとする前に、テストを書く。それをファンクショナルテストという人もいるだろう。たとえばJUnitの40%は公開APIで使われている。60%は低レベルのオブジェクトに使われる。公開APIはテスティングにかなり向いている。この40-60という比率自身は問題ではない。10-90かもしれないし、90-10かもしれない。 スケールの間を移動できるのがTDDの利点だ。顧客との会話の中で、あるシナリオで期待される結果がわかったら、それをもとにテストを書くだろう。BDDは「受け入れテスト駆動開発」みたいなものだ。だけどスタイルの間にがっちりした壁をたてて、それらを区別するっていうのは間違いだと思うよ。
すみませんが後はどなたかよろしくお願いします。
*1:2010/10/13 平鍋さんのコメントを反映して修正しました。
