![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Open棟梁Project - マイクロソフト系技術情報 Wiki
予算に余裕の無い産業系案件の単体テストでは、イベント単位テストが慣例であるが、
予算が潤沢な金融系の案件では、クラス・メソッド単位テストが慣例となっている。
これを真に受けると、
クラス・メソッド単位テスト方式の方が品質が出る様に見える。
しかし、実際は逆に問題の方が多いと考えている。
これに合致する、事例をサンプリングする。
アポロ計画を成功させたオール・アップ方式をサンプリングして説明する。
ロケット機体を一段ずつ開発し、
上の方はダミーを使って組み立て・発射テストを繰り返すというステップ・アップ方式
すべての段をしっかりした検証をしながら製作して
ダミーを使わず一気に全体を試験するというオール・アップ方式
アポロ計画では、
工期の短縮に成功する。
また、それだけではなく、
部品１つ１つの信頼性を高めることにも成功している（理由は以下）。
大きな組織が動き出す知恵 - PageTAKA's blog
http://pagetaka.hatenablog.com/entry/2013/01/17/%E5%A4%A7%E3%81%8D%E3%81%AA%E7%B5%84%E7%B9%94%E3%81%8C%E5%8B%95%E3%81%8D%E5%87%BA%E3%81%99%E7%9F%A5%E6%81%B5
縦割りのフォルトラインは非常に大きなマイナスを生んでいる。
（この商店街の寄り合い文化が「船頭多くして船山に登る」という状況を作り出している）
オール・アップ方式の利点は、
説明可能である。以下、これを説明する。
当該システムで実行され得る
データパターンを考慮したテストが必要な機能を除いて
フレームワーク単独の単体テストを行わなくてもほぼ問題が出ない。
（と、前述のオール・アップ方式と同じ結論になる）
また、イベント・ドリブン・プログラミングの
プログラミング・パラダイム上で動作するカスタムコントロールなどは、
カバレージの指標だけでは十分ではなく、
システムによって（ユーザプログラムが側から）十分に叩かれる必要がある。
（こちらも、前述のオール・アップ方式と同じ結論になる）
コスト的に有利である。
これにより、
工数・工期を品質作り込みに利用し、品質の向上を図ることができるものと考える。
従って、検査（バグ抽出）は
