Index: [Article Count Order] [Thread]

Date:  Sun, 1 Oct 2000 23:31:42 +0900
From:  Takao Nakaguchi <takao-n@....jp>
Subject:  [XP-jp:00995] Re: テストのためだけのメソッド
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <39D749DE.7E3E4274@....jp>
References:  <B5FCE0A0.3C23%khosokawa@....com>
Posted:  Sun, 01 Oct 2000 23:27:42 +0900
X-Mail-Count: 00995

中口です。

ちょこっと参加させてください。


アクセス権による視点の違いから考えてみます。

(Javaの場合)アクセス権は、
・クラス内部
・派生クラス
・同じパッケージのクラス
・クラス外部(クラスを使う側)
の 4つに分かれますよね。

で、通常 XP でテストというと、4番目のクラス外部からのテストのことを指して
ます。これは、クラスを使う側から見てクラスが正常に振る舞うことを確かめる
ことがその目的だからだと思います。

存在しないメソッドやプライベートメソッドを使ってテストを書く場合、今まで
クラスを使う側の視点でテストを書いていたところに、違う視点(テストする人
視点。クラス内部視点)が持ち込まれることになります。もちろんそれに付随する
情報(このメソッドはテストだけとか、他のプライベートメソッド、変数等)も
念頭に置く必要が出てくるので、テストを書く作業が必要以上に複雑なものに
なってしまう危険性を感じてしまいます。

だからってそのままにはしておけないので、
クラス外部から呼び出せるメソッドを使った通常のテストクラスの他に、
・InnerTestCase クラス
・DerivedTestCase クラス
・PackageLevelTestCase クラス
を別のテストクラスとして作成するってのはどうでしょうか?
(先程のアクセス権のところに対応しています)
InnerTestCase クラスでは、リフレクション用のヘルパメソッドを用意して。


class SqlHandlerInnerTest extends InnerTestCase{
  public void testCommandMemberValid(){
    String sql = "select * from test";
    SqlHandler h = new SqlHandler(sql);
    assert(getMember(h, "command") == sql);
  }
};

こんな感じで。(コードはかなり適当)
テストクラスを別に作る労力はいりますが、

・テストされるクラスをいじらなくて良い。
・テストを書く際の視点が分かれ、それぞれのテストの意味が明確になる

てな利点があるかと。


Takao Nakaguchi
takao-n@....jp