-
静的解析ツール → 今回でいうとSwiftlint
-
開発とテストの連携では、第一に「プロジェクト全体でどのような品質を確保すべきか」の品質要求の分析が重要
-
またアーキテクチャレベルで品質要求を分割し、別々に分析可能にするアプローチも品質要求の全体を扱う工夫として有効です。例えば課金システムや個人情報管理などハイリスクな責務のインフラとローリスクのサービスを設計で分離して、各品質確保の厚みや方針を別々に考えられるようにする
-
スクリプトテストと探索的テスト
-
要件と課題
-
「本当に必要なテストを行えているか」を担保する手段
- 同値分割/境界値分析
- ドメイン分析
- 組み合わせテスト
- リスクベースドテスト
-
"ロールや責務を置き換える"・"ロールや責務をモックする"という感覚を念頭に置いておくと良いでしょう。あるコンポーネントやオブジェクトそのものすべてを置き換えるという意味ではなく、ある側面を置き換える
-
テストダブルの分類
名称 | 説明 |
---|---|
スタブ | あるロールが任意の値を返すように置き換えるもの 固定値を返す |
モック | あるロールの入出力を監視し、なおかつそれらが正しいかを検査するように置き換えるもの 呼び出しが正しいかをテストできるもの |
スパイ | あるロールが出力したものを監視して後から検査できるように置き換えるもの レスポンスが正しいかをテストできるもの |
フェイク | あるロールとほぼ同じように入出力するように置き換えるもの ほぼ本物と同じように動作するもの |
ダミー | テストにまったく影響しないロールを置き換えるもの |
開発とテストの段取りを工夫する | Think IT(シンクイット)
- 項目をどのように作っていくか? 仕様書・設計から、品質要求を細分化・具体化。このとき網羅性を確保 言語化されていない要求(ネットワーク不通時に落ちないなど)を補う必要がある。