Index: [Article Count Order] [Thread]

Date:  Fri, 02 Aug 2002 01:25:36 +0900
From:  Eiji Yamane <e-yamane@....jp>
Subject:  [XP-jp:03632] Re: ソフトウェア品質指標についての考察
To:  extremeprogramming-jp@....jp
Message-Id:  <20020802004737.E4D0.E-YAMANE@....jp>
In-Reply-To:  <001201c23846$27f578a0$85222fc0@....jp>
References:  <20020731004246.2537.E-YAMANE@....jp> <001201c23846$27f578a0$85222fc0@....jp>
X-Mail-Count: 03632

山根です。
なひさん、こんばんは。

On Wed, 31 Jul 2002 12:55:48 +0900
"NAKAMURA, Hiroshi" <nakahiro@....jp> wrote:

> なひです。
> 
> なひは、カバレジ100%でないテストは犯罪、という観点から、
> XPのUTにおいてカバレジは常に100%であるべき、という立場です。
これは、僕の考えとはちょっと違うのですが、
結論としては被る部分が非常に多いので、
別に議論するつもりはありません。

したとしても、それは自分のめんどくさがりやな面が強調されるだけで、
ぼろ負けするので、負け戦はしません。f(^_^;
#と言うわけで、なひさんの考えで私は前科数十犯です。

> XP的には、基本的には常に100%になる、ということなんじゃ
> ないでしょうか。テストファーストで実装した以上、
> 実装にテストでカバーできない部分があったら、
> YAGNIにひっかかるんじゃないでしょうか。
引っかかるでしょうね。
でも、僕の場合メインの言語がJavaなんでどうしてもうざい、
例外はキャッチしないといけなくなってしまいます。
ですので、catch句の中まで入れれば、100%と言うことは
基本的にはありません。

例えば、、、(Java知らない人ごめんなさい)
web.xmlのenv-entryタグからの情報の取得に失敗するような場合、
僕はテストを書きません。(ユーザーさんにweb.xmlを開放しない限り)
#上位に返却するのもなんか気に入らないので、大抵
#RuntimeExceptionでかぶせてしまいます。

それは、実行時には正しくセットされるべきであって、
そのクラス単体の責務ではないからです。
僕は、上記のようなケースでは、
NamingExceptionをキャッチして、RuntimeExceptionでスローしなおす
と言うコードに対するテストコードは書きません。

これは受入れ試験の領域で判明しますし、しかも環境設定ミスですから、
バグの領域(コンテナも含めて)に入ると僕は考えます。

バグがあった時どうするかと言う試験は防御的プログラミングの
考え方であって、Contractに対する試験という
意味で趣向が変わってきますよね。

ただ、こう言うコードのテストを「書くべきだ」と言う人を否定はしないです。
書いた方が書かないよりは良いのは自明だからです。
「でも、他にもっとやるべきことないですか?」
僕の主張は徹頭徹尾それだけです。

> 「XPのプラクティス(の一部)を『遵守』できているかどうか」
> を測る指針として考えるとどうでしょうか。
> カバレジはよい指針になりそうな気がしませんか。
おっしゃる通りだと思います。

が、プラクティス自体を『遵守』すること自体に
あまり重きを置いていないのです。

早く、高品質とメンバーが自信を持って言えるシステムを
構築できさえすればそれでよいので、
「XP的ではない!」と言われることとかはあまり気にはしません。

そう言う意味で、自らの正当性を保証するための
労力を僕は(必要がないかぎり)避けたいと思っています。
#求められたら*仕方がないので*やりますが、、、f(^_^;

> 上で「基本的に100%」と書きましたが、いくつか難しい
> 部分もあって。。。最近の言語においては、例外のthrowも
> カバレジを取るべきパスの一つですが、
> RuntimeExceptionをどれだけ効率的に、どこまで追うか、
> で最近悩んでいます。

<<...snip...>>

> 例えばこんな例ですが、メソッドrateFor100には、
> i == 0を渡された場合にArithmeticExceptionを投げるという
> パスがあります。テストファースト時に、
> ソフトウェアテスト工学的によく訓練されたテスターの
> 帽子をかぶっていれば、この程度のパスは事前に予想して
> テストが書けると思います。とはいえ、同じRuntimeExceptionでも、
> Java特有のCastErrorExceptionなんかは、実装を見るまでは
> 予想しきれないことも多いでしょう。そうすると、
> UTではカバーできない、実装により織り込まれたパスが
> でてくることになります。
予想しきれないことも多いでしょうと言う点は確かにあると思います。
が、予想出来た場合は、事前条件として、「@precondition i != 0」と言う
キーワードを入れておけば、それは呼び出し側の責務違反ですから、
*Foo*としてテストする必要はないと僕は思います。
同様に、nullが渡ってくると困る場合も、
大抵「@precondition param != null」とか、
書いてごまかします。

> 結局、よいテスターが頑張る、しかないのかなぁ。
個人的には、良いテスターが頑張るより、良いプログラマーが、
コードを記述する段階でシンプルなデザインで、明らかに誤っていないと
*思われる*コードを書いてくれるほうが嬉しいです。

山根 英次(Eiji Yamane)
  mailto:e-yamane@....com
    http://www.ne.jp/asahi/e/yamane/software/