オブジェクト指向設計と試験性

1.試験性とは

1. テストでバグを発見。
2. バグを修正。
3. バグを修正したときに、バグを作りこむ。もしくは、バグを修正したことによって、今まで顕在化していなかったバグが顕在化する。
   （バグが2つあり、1つのバグがもう一つのバグを発見しにくくすることは良くある）
4. 1に戻る。
5. いつまでたってもバグ曲線が収束しない・・・。
6. デスマーチ（※２）へ

2.試験性を考慮した設計にする

1. 設計時、テスト（特に単体テスト）の自動化がしやすい箇所としにくい箇所を明確にし、自動化がしにくい箇所を極力少なくする。
   　だるまの経験では以下の箇所がテストの自動化がしにくいです。
   　・画面系（※１）
   　・処理に時間がかかる箇所（例えば、ネットワークが関係する箇所）（※２）
   　・外部からデータを読んだり、外部へデータを保存する箇所（DBアクセス、ファイルアクセス、標準出力・・・）（※３）
   です。
   
   
2. テスト用のスタブやドライバが作成しやすい設計にする。
   　スタブとはテスト時において、テスト対象クラスが使用しているクラスの代わりとなるクラスのことです。
   　1番ではDBアクセスを使用しているクラスを使っているクラスはどうやってテストするのかという問題になります。そのようなときはモックオブジェクト（※４）を作成して対応します。その際は、テスト対象のクラスがモックオブジェクトを使用してテストが出来るような設計にしておく必要があります。
   
   　ドライバとはテスト時において、テスト対象クラスを呼び出すクラスのことです。
   　例えば、ある属性に対してsetter（※５）だけがある場合、テストプログラムからこのsetterを呼び出すことになりますが、これだけではちゃんと値が設定されたのかがわかりません。このようなときはgetterも作成してください。
   
   
3. 変更が発生しやすい箇所と、変更が発生しにくい箇所を明確にする。また、変更が発生しにくい箇所を極力増やす。
   　可能な限り共通化を行った方が良いということです（※６）。
   　それから、データは処理に比べて安定（変更がかかりにくい） ですので、分けておくと良いと思います。
   
   
4. 双方向の関連や双方向の依存を避けます。双方向の関連は単方向の関連に出来ないか、双方向の依存は単方向の依存に出来ないか、再度確認します。
   　ちなみに、双方向の依存が特にやばいです。
   　
   　双方向の関連（双方のクラスがもう片方のクラスのオブジェクトを保持しあう）は、ガーベッジコレクションのアルゴリズムが参照カウント方式の場合に面倒です（何もしないとメモリリークになる）。
   　
   　双方向の依存（双方のクラスがもう片方のクラスのメソッドを呼び出しあう）ですが、単体テスト時にクラス単位で単体テストが実施できず、２つのクラスを同時に行うことになるので、テストがしにくくなります。
   　※クラス図的に双方向に依存してなくても、内容的に双方向になっているのもダメです（これはさらにまずい）。単体テスト時は問題なくても、後で（仕様変更時など）影響範囲を洗い出すのが大変になります。
   　
   
   
5. トレースログ（デバッグログ）の埋め込み
   　単体テスト時はトレースログがなくても何とかなりますが、結合試験以降はトレースログが入ってないと、問題発生時、解析が困難になります。
   　さらに、詳細なことを言うと、一般にログの出力先や出力レベルは設定ファイルに設定することが多いのですが、この設定ファイルの厳格なチェックも必要です。
   　※単に困るだけでなく、セキュリティ上の問題もある。
   
   　以下も必ず確認しましょう。
   　・ログの設定ファイルは解析可能か？
   　　→解析不能ならアプリケーションを起動させない。
   　・ログの設定ファイルに指定された出力先は存在するか？書き込み可能か？容量は大丈夫か？
   　　→ダメならアプリケーションを起動させない。
   
   
   
6. 設定メソッド（setter）などでの厳格な引数チェック、状態チェック
   　共通クラス、ライブラリ作成時は厳格にチェックしましょう。
   　その他、画面や外部ファイルからの入力データも厳格にチェックし、NGの場合は画面にてユーザに知らせる、ログに出力する（もちろん、どこが悪くて、どのように対処すればよいのかが分かるように）といったことが必要です。
   　オブジェクト指向の3大要素の1つであるカプセル化はこのためにあるといっても良いくらいです。
   　これが行われていると単体試験でより不具合を検出でき、結合試験以降のバグ発生を抑え、工数を減らすことができます。
   
   
7. いくらテストをしても、全パターン試験はできないことを意識する
   　意識する前に、知らなかった人は、まず、上記の内容を知るところから始めてください。
   　ホワイトボックスにて命令網羅、条件網羅などがありますが、仮にそれで全網羅させても、それで網羅させただけです。
   　たとえば、
   　a = b / c;
   　というプログラムがあったとき、c=0のとならないように作成されていなければバグですが、これだけでは命令網羅・条件網羅のいずれでも、c=0のパターンは出てきません。
   　他にも、マルチスレッドプログラミングの場合、すべてのタイミングを網羅するなど、パターンが多すぎて無理なのですが・・・。
   
   　なので、「いくらテストをしても、全パターン試験はできないことを意識する」ことが重要なのです。
   　上記を意識すると、もちろん、設計工数、プログラミング工数が増大します。しかし、オブジェクト指向設計、プログラミングはそうでない設計、プログラムよりはその増大する工数を抑えられると思います（カプセル化は特に役に立つ。）。
   
   

3.参考文献など