矢崎です。
Kaoru Hosokawaさん wrote:
>
> > 例えば、
> >
> > aTestTarget.setNumber(5);
> > assertEquals(wkInt,5);
> > aTestTarget.setNumber(1000);
> > assertEquals(wkInt,1000);
> >
> > のようなテストは、既に値が入っている、Number属性
> > に対して、setNumberが正しく値を書き換えたかをテスト
> > する流れとしては妥当だと思います。
> > （もともと５が最初に正しくセットされていなければ、
> > 正しく1000で書きかえられたとは言えないので）
>
> テストの効率（実行時間）を考えると、上記の方法がいいように思います。でも、実
> 際に test メソッドが失敗した時、（二つ assert があるので）どの assert で失敗
> したか探す必要があります。私は、test メソッドは一つの事を試す方がいいと思い
>
assertXXXXは、それぞれ、メッセージを表示するものと表示しないもの
のペアになっています。
例えば、[XP-jp:00263]でお送りしたassert一覧の５と６はペアです。
5.static public void assertEquals(String message, long expected, long actual)
message テストが通らなかったときに表示したいメッセージ
expected 比較したい一方の数
actual 比較したいもう一方の数
判定方法 expectedとactualが等しければテストOK。それ以外はテストNG。
6.static public void assertEquals(long expected, long actual)
expected 比較したい一方の数
actual 比較したいもう一方の数
判定方法 expectedとactualが等しければテストOK。それ以外はテストNG。
ですから、１つのテストメソッドの中で複数のassertを使う場合には、
メッセージ付きのほうを使えば、どのassertで失敗したかはわかり
ます。が、しかし、、、、
> ます。上記の例は、２つの test メソッドに分けた方がいいと思います。以下が私の
> 分け方です。
>
>
> public void testSetNumberOnce() {
> // ...
>
> aTestTarget.setNumber(5);
> wkInt = aTestTarget.getNumber();
> assertEquals(wkInt, 5);
> }
>
> public void testSetNumberTwice() {
> // ...
>
> aTestTarget.setNumber(5);
> aTestTarget.setNumber(1000);
> wkInt = aTestTarget.getNumber();
> assertEquals(wkInt, 1000);
> }
>
> testSetNumberOnce() で、setNumber() が正しく値をセットすることが確認できます。
> testSetNumberTwice() では、setNumber() が正しく値を書き換えるかどうかが確認
> できます。 testSetNumberOnce() が、成功した場合、testSetNumberTwice() の
> setNumber(5) の後に、assert は必要ないと思います。
>
> その時のテストによると思いますが、私は「一つのテストメソッドに一つの assert」
> ではないかと思います。
>
ホソカワさんの上記ご意見には、納得するものがあります。
少なくとも、私の出した例でいえば、ホソカワさんの書かれた
ほうがいいように思えます。
＃絶対1つかといわれると、まだ心はゆれますが、できるだけ
１つに近づけるようにしたほうがいいのかもしれませね。これ
については、これからJUnitをいろんなケースで使ってみて
考えてみたいと思います。ホソカワさんも使ってみてください。
レポートしあいましょう。
--
矢崎 博英 <firo@....jp>