| 項目 | テストコード | 定量的測定 |
|---|---|---|
| 動作の正しさを保証 | ✅ できる | ❌ できない |
| 変更の安全性を確認 | ✅ できる | ❌ できない |
| ユーザーシナリオの検証 | ✅ できる | ❌ できない |
| 迅速なフィードバック | ✅ できる | |
| バグ修正コストの削減 | ✅ できる |
- ✅ テストコード → プログラムが意図通りに動作することを保証
- ❌ 定量的測定 → 品質の「傾向」や「リスク」を評価するのみ
📌 例:
- コードの複雑度が低くても、動作が正しいとは限らない。
- コーディング規約を守っていても、バグがないとは限らない。
- ✅ テストコード → リファクタリングや仕様変更の際、既存機能が壊れていないことを確認できる。
- ❌ 定量的測定 → 品質の変化は分かるが、動作が正しいかどうかは分からない。
📌 例:
- コードの複雑度を下げるリファクタリングをしても、意図しない動作変更が起きる可能性がある。
- メトリクス上の品質スコアが改善しても、バグが混入していたら本質的な品質は低下する。
- ✅ テストコード → 「入力Aに対して期待する出力Bが返るか？」を直接確認可能。
- ❌ 定量的測定 → コードの状態を分析するだけで、実際の動作の正しさは分からない。
📌 例:
- ユーザーが期待する動作を保証するには、テストコードが必要。
- ✅ テストコード → CI/CDと組み合わせることで、開発のたびに即座に品質チェック可能。
⚠️ 定量的測定 → メトリクスの変化は分かるが、エラー発生後に手動で確認する必要がある。
📌 例:
- CI/CDでテストが実行されれば、コード変更のたびに品質が保証される。
- ✅ テストコード → 事前にバグを発見できるため、修正コストが低くなる。
⚠️ 定量的測定 → バグ発生後の対応となるため、修正コストが増大する。
📌 例:
- 単体テストで事前にバグを発見 → 低コストで修正可能。
- 本番環境でバグが発生 → 影響範囲が広がり、修正コストが増大。
✅ 定量的測定だけでは「品質の傾向」は分かるが、「品質の保証」はできない。 ✅ テストコードがあれば、実際の動作を検証しながら品質を向上できる。 ✅ 継続的な開発・改善のために、テストコードを導入すべき！
public