« [記事紹介] MSDN ライブラリ ~ TDD Support with the Generate From Usage Feature | トップページ | [ブログ紹介] Kanazawa.process »

2009年6月27日 (土)

[記事紹介] InfoQ ~ Kent Beck氏、 ごく短期のプロジェクトではテストを省略することを提案

この記事は、 Kent Beck 氏が彼の blog に投稿した "To Test or Not to Test? That’s a Good Question." ( May 14th, 2009 ) という記事とそれに寄せられたコメントを、 紹介しています。 この記事のタイトルは、 物議をかもすことになりそうです。

InfoQ: Kent Beck氏、 ごく短期のプロジェクトではテストを省略することを提案
2009年6月21日 ( 原文は 2009/6/18 )

予備知識として、 現在 Kent Beck 氏は、 JUnit Max という名前の有償の Eclipse プラグインを数名で開発しているということを知っておいてください。 ( 参照 ⇒ 平鍋健児氏のブログ An Agile Way : 「JUnit Max - Kent Beck のプログラミングについての実験と人生」 2009/04/19 )

それでは、 InfoQ の記事から、 Beck 氏の文章を引用した部分。

Max を始めたとき、 最初の1か月間は自動テストを一切やりませんでした。 すべて手動でテストしていました。 最初の数名の契約者を得てからは、 立ち戻って、 既存機能のためのテストを書きました。 もう一度言いますが、 このような順番にしたおかげで、 単位時間当たりに実行できる有効な実験の数を最大化できたと思っています。

テストは省略していない、 のです。 「すべて手動でテストしていました」 と書いています。 すなわち、 記事のタイトルにある 「テスト」 とは、 コーディングされたユニットテストのことである、 と解釈しなければなりません。
しかしおそらくは、 きちんと読まずに記事のタイトルだけに引き摺られて、 「Kent Beck がテストしなくて良いと言っていた」 と誤解した議論が出てくると思います。

Beck 氏の主張は、 「ショートゲームの場合は、 ユニットテストを省略したほうが、 トータルで得をすることもありえる。 ( だから、 そう判断したときは、 ユニットテストを書かない。 )」 ということでしょう。
※ ショートゲームと限定しているのは、 ロングゲームの場合は、 自動実行できるテストスィーツの価値が遥かに高くなるので別だということでしょう。

このことについて、 氏自身 「ルールが変わった」 と感じておられるようです。 しかし、 原則は変わっていません。
以前から、 GUI はユニットテストから外していました。 なぜなら、 GUI のユニットテストを書くことは時間が掛かるので、 手動テストで済ませておいたほうが、 トータルでは得だからです。 以前から、 簡単な getter / setter ( プロパティ ) はユニットテストしなくてもよいとされていました。 まず間違えようがないコードに対してユニットテストを書くことは、 トータルではもったいないだけだからです。

もうひとつ。 Beck 氏のブログに書かれていないこと。
ユニットテストを省略すると判断したとき、 そのときは事前にテストを考えることもやめてしまうのか?
私には、 それは信じられないことです。 やはり、 テストを考えてから、 コードを書いていると思います。

|

« [記事紹介] MSDN ライブラリ ~ TDD Support with the Generate From Usage Feature | トップページ | [ブログ紹介] Kanazawa.process »

記事紹介」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: [記事紹介] InfoQ ~ Kent Beck氏、 ごく短期のプロジェクトではテストを省略することを提案:

« [記事紹介] MSDN ライブラリ ~ TDD Support with the Generate From Usage Feature | トップページ | [ブログ紹介] Kanazawa.process »