JUnitの歴史とテスティングの未来（Kent Beckインタビュー）

平鍋さんがTwitterで、Kent Beckのインタビューについてつぶやいていたのが目に留まったのですが、
リンクが張られていなかったのでソースをお聞きしたしたところ、
「協力して訳してみませんか」という話になりました。
大して英語できないし、何よりアジャイルソフトウェア開発についての知識が乏しいので躊躇しましたが
「このチャンスを逃してはもったいない」と、思い切って参加させて頂きました。

元ネタは「Software Engineering Radio」のインタビューです。
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

以下、平鍋さんの訳の続きです。

Martin: （JUnitはJavaですがいくつかの言語で同様の実装があります…という話の文脈で）*1
こういった動きをどう思いますか？
Kent: いくつかのレベルで説明できる。
一つは「テストのための共通な何か」という意味で設計がうまくいったこと。
単独で動かしたり、干渉させずにお互いを組み合わせることができる。
誰でも実装用の言語でこういったことが全てできる。
実装用の言語の中にテスト用の言語を持たないことに利点があるだけじゃなく、
テスト用言語の中に実装用の言語を持つことにも利点がある。
実装用言語とテスト用言語が同じJUnitのように。
一種、デザインツールの空間にdistractorがあるようなもので、
たくさんの機能を同じ基本的な形にまとめられる。
Martin: まだ、活動しているのですか？
Kent: うん。毎週、GoogleのDavid Saffと一緒に数時間作業しているよ。
Martin: 毎週？
Kent: うん、ほとんど。
Martin: Cool! 次のバージョンについてプランがあるんですか？
Kent: うん、大きなテーマではないんだけれど。
最新のバージョンでは、本当にcoolな機能をリリースしたし。
コミュニティで広まっていっているようなね。
13年間プロジェクトを続けてきたことの利点の1つは、忍耐の重要性について学べたことだ。
もし新機能を取り込もうとするのなら、素晴らしいと感じるんじゃないかな。
5年後、みんなが使っていたら、本当にcoolな機能ということになるね。
使い始めてまだ3年しか経っていないから、まだ、coolかどうかはわからないと思うよ。
僕らは「ルール」と呼んでいるんだけど…
簡単に説明する方法は何かな…
テストを実行すると「chain object」が作られる。
あるオブジェクトはメッセージの前に動いて、別のオブジェクトはタイムアウトを検知して 、
さらに別のオブジェクトはエラーを報告する。
「ルール」を使えば、「object chain」を挿入することができる。
これはテスト用のメタオブジェクトのようなもので、
テストの共通性を捕らえるために継承を使わなかったことよりもむしろ、
こういったcoolな機能を使うことが重大だった。
今ではもっと柔軟にコンポジションを使える。
もし、JUnitのcoolな機能を探しているのであれば、これがそうなるかな。
Martin: unitテスト用のコードで使ったものを再利用することが特色なんですか？
Kent: 13年間この機能なしでやってきたから、これが特色になるのかわからないね。
でも、テストの共通性を捕らえるには間違いなく便利だと思う。
テストでは式宣言のようなことに力を入れている。
物語のようにテストを読むことができなければならない。
ルールはテストをお膳立てするための手段であると同時にシンプルにしてくれる。
テンポラリーフォルダを作るルール設定できる。
テストをするのにはファイル操作すれば良く、テストが終わればフォルダは自動的に削除される。
テストを読めば、テンポラリーフォルダを見つけ、そこからファイルの操作を続けたら良いことがわかる。
Martin: 再利用するためのものというだけでなく、より表現が豊かになったということですか？
Kent: その通り。なぜなら全てのテストにはストーリーがあるから。
テストには起承転結や、話しの流れといったものなどがあべるきで、
テストの観点をテストから読み出すことができなければいけない。
ルールはテストの背景を設定する別の方法を提供してくれる。以前あったものより豊かな方法で。
Martin: 取り入れられるのはバージョン4.…
Kent: 8。多分。
Martin: 4.8？
yent: この機能が入るのは。
Martin: すごい。
Martin: TDDで作業してきたおっしゃっていました。簡単にTDDとは何か紹介してもらえますか？
Kent: うん。crazyなアイディアで…Oh！最高なアイディアはcrazyなもんだよ。
もし、crazyなアイディアがあるのなら、それは本当に役に立つ。
素晴らしいアイディアなんかよりcrazyなアイディアの方が貴重。
（TDDは）crazyなアイディアで、コードを書きたかったら、
始めにしなければいけないのは、失敗するテスト書くこと。
このテストはイメージしたコードが適切な場合にのみ成功するテスト。
これはプログラミングの作業の流れを逆さにしてしまった。
Martin: TDDにおいて、あなたが考える最も重要な観点は何だと思いますか？
例えば、はじめに設計について考えるとか、使われるクラスの観点から実装するとか。
Kent: 数年間TDDをした後、いくつかの機能性をイメージして、
次にどうやってそれらをテストするかを考えるようになった。
かつてはいつも、機能性をイメージして、サブクラスがどうのといった実装について考えていた。
今では、機能性について考え、それからどうやってテストするかということを考えている。
実装と、「実装が正しいこと」をどうやって知るかを同時にイメージするようにしている。
これは大きな仕事で、大きすぎて時々頭がいっぱいになってしまう。
2つに分けられるのであれば、「どうやってテストをするか」をはじめに取り組む。
「どうやってテストするか」を考えるのに、小さくて、ストレスが少なく、問題に焦点を当てやすいものに取り組む。
商用でないプログラムのテストを書くのであれば、僕は非常に実績を挙げているので、こんなことは気にしない。
スリングコードや、マニュアルでチェックして「きちんと動くプログラムを作れるのだろうか」と言いたい。
作れることがわかった時が、問題の取り組み方を変える良い機会だ。
以前のように、ちょっと実装しては、どうやってテストするかを考えるよ。

Podcastの経過時間は16:40です。

平鍋さんもおっしゃっていますが

正確に訳しているのではなくて、ポイントを日本語にしていきたい

とのことなので悪しからず…
とは言え、勘違いしていますよとか、ココはこういうことを言っているんですよと言ったツッコミがあれば、
ぜひともお願いします。
この辺の話についておすすめの資料があれば教えて頂けるとうれしいです。
オブジェクトチェインについても良くわかりませんでした。
TDDは5年以上前に試したきりなので、今TDDをやってみたらわかることなのかも知れませんね。

＞平鍋さん
声をかけて頂いてありがとうございました。
「わからないこと」にこだわり過ぎず、引き続きインタビューを聞いていきます。

ちょっと突くと知りたいこと、やってみたいことがたくさん出てきますね。
だからこそ楽しいんですけれど。

後でレイアウト変更しよう…

*1:平鍋さんのコメントに基づいて追記しました