« [研修]ISTQB認定テスト技術者-Foundation Levelトレーニング | トップページ | 【受付開始】WACATE 2008 夏 ~どっぷりつかろうテスト設計~ »

ユニットテストを書かない方法

TEFでもTDDや単体テストの話題で持ちきりですが、

極力ユニットテストを書かずに品質を確保する方法 by ひがやすを blog

やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。

ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。

後述にもありますが、「ユニットテストは工数がかかる」という意見に対する対案のようなもので、せっかく書いたテストコードをより効果的・効率的にするための工夫ですね。

事実、ここ数年、「ユニットテストは工数がかかる」と思っている人と「ユニットテストを書いたほうが最終的にはコストが下がる」と思っている人の会話は平行線のままです。

このような状況を改善するために考えたのが、「Programming First Development」のなかで、バグったところ(とその周辺)のみユニットテストを書くという方法です。このやり方なら、ユニットテストを書く工数は、かなり減ります。そして、偏在しているバグを効率よくつぶすことができるのです。

著者の「ユニットテストの工数を少なくしつつ、品質を保つ」という試み・着眼点はすごく興味惹かれますね。ユーザにまずは動かしてもらうという方法以外にも、考えたらいろいろ思いつきそう。難易度・重要度マトリックスを作って、ユニットテストの強弱をつけるとか。ただ、個人的な意見ですが、「ユーザにまずは動かしてもら」ったとしても、開発者側が思ってるほど協力的ではない場合もありそう。その場合は、バグったところの他のバグは見つけられるかもしれないが、そもそもユーザがあまり操作してくれなかった箇所・機能なんかは少し不安が残るかもしれません。


|

« [研修]ISTQB認定テスト技術者-Foundation Levelトレーニング | トップページ | 【受付開始】WACATE 2008 夏 ~どっぷりつかろうテスト設計~ »

コメント

>バグったところ(とその周辺)のみユニットテストを書くという方法
ユニットテストの目的をどこに置くかであると思います。

リファクタリングをする目的であれば、これだけでは足りないと思います。
ユニットテストの本来の目的は、「前と同じように動く」ことであると思うので、バグったところのみというのは目的から外れるのではと私は思いますが、いかがでしょうか?

投稿: ただいま修行中 | 2008年5月 3日 (土) 23:03

川西 @ TestLink日本語化部会です。

私もこの記事を読みました。(というより、直接講演を聴いてきました。)色々、考えさせられてとても為になりました。

ただ、バグとユニットテストという観点で考えると、
(1) 何のためにユニットテストをするか?バグを見つけるため。
(2) では、何のためにバグを見つけるのか?バグを直すため。
(3) バグを直すためにはどうすればいいか?バグの原因を特定する必要がある。
というふうになるかと思います。
多分(3)のバグの原因の特定というのが、コンポーネントテストをしっかりやっていないと難しいのではないかと考えています。「バグったところ(とその周辺)のみユニットテストを書く」ってバグの原因が魔法のように分からなければものすごく大変だと考えています。この辺りはどう思われますか?

# そういえば実家が三ッ池公園から近いです。もうちょっと綱島方面でダイクマやラウンドワンがあるあたりです。現住所は川崎です。

投稿: Toshiyuki Kawanishi | 2008年5月 5日 (月) 22:47

>ただいま修行中さん

「バグったところ(とその周辺)のみユニットテストをする」というのは
単体レベルでもっとも効果的にテストができるところだけテストを実施し、
・後工程で発見されたときにコストが大きいものをなくす
・ユニットテストの敷居を下げる
という効果を著者は狙っているのではないかと思っています。
(私は後者に重きを置いているように解釈しました)

ごく一般的なユニットテストで検出できたバグが後工程で見つかる、といった
問題点は考慮済み、なのかなあと思っています。


>Toshiyuki Kawanishiさん

講演に参加されていたのですね、僕もパネルはいってみたかったですー。
おっしゃるとおり、原因特定については言及されていない気がしますが、
今後の実践を経てから、そのあたりを著者から聞いてみたいですね。

# テストの観点で「演繹的」「帰納的」とかってあるのかなあ

ちなみに僕は公園近くの高台なので毎日帰宅するときの上り坂が大変です。。。

投稿: softest | 2008年5月 7日 (水) 12:39

コメントを書く



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




トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/155415/20507755

この記事へのトラックバック一覧です: ユニットテストを書かない方法:

« [研修]ISTQB認定テスト技術者-Foundation Levelトレーニング | トップページ | 【受付開始】WACATE 2008 夏 ~どっぷりつかろうテスト設計~ »