ひがやすを blog このページをアンテナに追加 RSSフィード

Information

2008-04-23

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

今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。

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

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

これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。

これまでは、「ユニットテストは、できるだけ書いたほうがいい」というのが一般的な見解でした(と思う)。でも、「そういわれても、ユニットテスト書くのも工数がかかるし」という人が多くて、ユニットテストが普及していないのも事実です。そういう人たちに対して、「ユニットテストを書いたほうが最終的にはコストが下がるんだ」と説明しても、あまり納得感はないでしょう。事実、ここ数年、「ユニットテストは工数がかかる」と思っている人と「ユニットテストを書いたほうが最終的にはコストが下がる」と思っている人の会話は平行線のままです。

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

また、最初にユーザに実際に動かしてもらっているので、開発者が、仕様を勘違いするという「仕様バグ」をほとんどなくすことができます。修正が大変なのは、「仕様バグ」です。実装バグは、後から見つかっても、直ぐに修正することができるでしょう。

和田さん、太田さん、会場のみなさんとどういうディスカッションができるのか、本当に楽しみです。

Permalink | コメント(4) | トラックバック(0) | 12:49 極力ユニットテストを書かずに品質を確保する方法を含むブックマーク 極力ユニットテストを書かずに品質を確保する方法のブックマークコメント

コメントを書く

Seasar2やりたいSeasar2やりたい 2008/04/23 22:46 どうも、本日の飲み会では、一方的に名刺をいただいて大変失礼しました。
正直、緊張してましたww
別途メールを送らせていただきましたが、ご都合がつけば是非、私達の飲み会にもいらしてください。

通りすがり通りすがり 2008/04/24 14:48 >tさん
ユニットテストは検算みたいなものなので、ユニットテストを成功したことを以ってテスト対象ソースもユニットテストソースも正しい、とするしかないのではないでしょうか。

まあ確かに、誰もが思う疑問ですよねｗ＞ユニットテストのテスト

ykyk 2008/04/26 00:47 ユニットテストのテストなんて馬鹿げている。
テストの仕方が悪いだけ。

本質はDOTCH?本質はDOTCH? 2008/04/26 13:08 「仕様は変わるもの」という前提でユニットテストのメンテナンスに工数がかかるという人と、「綺麗なソースを維持する」ためにはユニットテストが足りないとリファクタリングし難い＆品質を担保できない、と主張する自分の間でまさに平行線でしたw
本質的にはどうあるべきなんでしょうね・・・

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
 ゲスト

画像認証

トラックバック - http://d.hatena.ne.jp/higayasuo/20080423/1208922541
リンク元