|
|
|
| オブジェクト指向の再定義[7] - EoTとユニットテスト |
|
|
|
|
|
テスト容易性(EoT=Ease of Testing)が設計品質を高める、ということを以前書
いた。もう少し具体的な根拠を書きたい。
ユニットテストをたくさん作るということは、設計に対してどんな意味を持っ
ているのだろう？物理的にいうと、「プログラムのエントリーポイントを増や
している」ということになる。
|
|
エントリーポイントとは、プログラムのスタート地点である。通常であれば、
プログラムはmainという名前の決まったエントリーポイントから呼び出され、
多くのモジュールを通過して終了する。しかし、ユニットテストを導入するこ
とによって、多くのテストメソッドが独立したエントリーポイントなる。main
以外にも多数のエントリーポイントが作られ、テスト対象のモジュール（クラ
スやメソッド）はさまざまな道筋（文脈）で呼び出されることになる。こうし
て多くの道筋で使われることで、モジュールの文脈依存が小さくなり、この結
果分かりやすく再利用しやすいテスト対象モジュールが取り出されることにな
る。さらに、モジュールの良い名前の採択が進む（文脈を表す名前でなく、責
務を表すメソッド名が現れる）。そして、――これが最も大切なことなのだが
――テストがあることによって以降のソフトウェアの変更が小さなコストでで
きるようになる（EoTは、EoC(Ease of Changing)の前提条件でもある）。
結論として、テストしやすい設計とは、「再利用性の高い設計」、「変更容易
性の高い設計」を、テストというより具体的な言葉によって方針化していると
いえる。以前、XPをやり始めたチームで、「このメソッドはユニットテストで
きません」という発言をよく聞いた。例えば、「タイマー起動である条件に合
致するユーザをDBから選択し、そのユーザのアドレスにメールを送る」という
メソッドをテストしようとしており、これはテストできない、という言い分で
ある。これは典型的な間違いだ。まず、「タイマー起動」、「DBから条件に合
致するユーザを選択」、「メールを送付」という3つに分けてテストできないか、
と考える。テストを基点としてモジュール分割を考えるわけだ。タイマー起動
のメソッドについては、時間をパラメータとし、すぐに起動されるイベントを
テストしよう。メールを送付できることをテストするのは難しい。そこでMock
（スタブ）を登場させる。メールの送付が他のクラスの責務であれば、自クラ
スのテストとしてはMailerMockを定義して、そこにメッセージが送られている
ことをテストすればよい。基本は、「テストしやすいように、責務を分割する」
ことだ。この指針が、EoT(Ease of Testing)の本質だ。テストはモジュール分
割のよいナイフになる。
|
|
|
つづき
|
この記事への評価にご協力をお願いします。
|
|
