![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Open棟梁Project - マイクロソフト系技術情報 Wiki
予算に余裕の無い産業系案件の単体テストでは、イベント単位テストが慣例であるが、
予算が潤沢な金融系の案件では、クラス・メソッド単位テストが慣例となっている。
これを真に受けると、
クラス・メソッド単位テスト方式の方が品質が出る様に見える。
しかし、実際は逆に問題の方が多いと考えている。
これに合致する、事例をサンプリングする。
アポロ計画を成功させたオール・アップ方式をサンプリングして説明する。
ロケット機体を一段ずつ開発し、
上の方はダミーを使って組み立て・発射テストを繰り返すというステップ・アップ方式
すべての段をしっかりした検証をしながら製作して
ダミーを使わず一気に全体を試験するというオール・アップ方式
アポロ計画では、
工期の短縮に成功する。
また、それだけではなく、
部品１つ１つの信頼性を高めることにも成功している（理由は以下）。
オール・アップ方式の利点は、
説明可能である。
以下、これを説明する。
カバレージ率（コード網羅率）
当該システムで実行され得る
データパターンを考慮したテストが必要な機能を除いて
フレームワーク単独の単体テストを行わなくてもほぼ問題が出ない。
（と、前述のオール・アップ方式と同じ結論になる）
また、イベント・ドリブン・プログラミングの
プログラミング・パラダイム上で動作するカスタムコントロールなどは、
カバレージの指標だけでは十分ではなく、
システムによって（ユーザ、ユーザ・プログラムが側から）
十分に叩かれる必要がある。
（こちらも、前述のオール・アップ方式と同じ結論になる）
コスト的に有利である。
これにより、
工数・工期を品質作り込みに利用し、品質の向上を図ることができるものと考える。
従って、検査（バグ抽出）は
