テスト可能設計についてのサーベイ +α
Introduction
テストの効率化を通じてソフトウェアの品質を改善するため、設計段階からテスト可能な設計が必要だと考えています。
テスト可能設計について、少しだけですが一般に行われている議論や研究についてサーベイします。
（続きは続きから）
Survey
継続的にテスト可能な設計を考える (2018/10)
リコージャパンで大規模ソフトウェアを設計されているであろう立場からの発表。
下記の問題の解決のための指針が示されています。
- 問題提起：テストにおけるコストパフォーマンス問題
- MVCの設計をどうすればMとCのみテスト可能になるか？
スクラップアンドビルドではなくリファクタリングをベースに考えている点がすごいと思いました。
回帰テストの合理化（影響範囲分析） (2018/1)
統合テストにおいて影響範囲に対するテスト漏れを防止する「影響波及パス分析法」の提案
DENSOで提案されている回帰テストのための技法。脱線しますがDENSOのソフトウェアエンジニアリング班はかなり優秀と聞いています。
- 従来から回帰テストは影響範囲内のみ実施
- 従来は影響範囲の分析を有識者のレビューで行っていた
- レビューのみではなく静的解析による影響範囲推定を導入
- 見落とし減 （→ 回帰テストの全数回しの必要性が下がる）
Addition
サーベイ先でも書かれていましたが、ソフトウェアコンポーネントのテストには下記の特徴があります。（下記の特徴を持つように設計するべきです）
| 役割 | 変更頻度 | テストコスト | クリティカル度 |
|---|---|---|---|
| Logic (Algorithm) | 低 | 低 | 高 |
| Data model (DB schema) | 中 | 中 | 高 |
| Controller | 高 | 低 | 中 |
| View (GUI) | 高 | 高 | 低 |
上記のように設計した上で時にはViewのテストを意図して省略し、Viewに混入する不具合をリスクとして受容する考え方も必要だと考えます。
Viewに混入する不具合を受容する設計としては下記のようなものが考えられます。
- Viewが動作不良を起こしても他のコンポーネントが正常に動作する設計
- Viewが動作不良を起こした際に、重要なデータが喪失しないような設計
- Viewが動作不良を起こしたときに、ユーザが容易に短時間で復旧可能な設計
一言で表すと、「任意のシステムにおける自動テスト不可能なコンポーネントは（納期逼迫などの最悪の場合を想定して）テストせずともリスク受容できるように設計すべき」です。
