1. 単体テストとは？
単体テスト（ユニットテスト）は、プログラムの最小単位（関数やクラスなど）を対象に、その動作が正しいかどうかを検証するテストです。一般的に、外部依存（DBやAPIなど）をモックやスタブで置き換えて、内部ロジックのみを検証します。
メリット：
・高速に実行可能
・不具合の原因特定が容易
・テスト駆動開発（TDD）との相性が良い
2. 結合テストとは？
結合テスト（インテグレーションテスト）は、複数のコンポーネントやモジュールを組み合わせた際の動作を検証します。DB接続や外部APIとの通信、システム全体のフローを確認するのに適しています。
メリット：
・実運用に近い状態での検証が可能
・モジュール間のやり取り・依存関係の問題を発見しやすい
3. それぞれのテストの限界と課題
両方とも完璧ではないため、「どちらか一方だけ」ではシステム全体の品質を担保できません。
4. 単体テストだけでは不十分な理由【実例】
実際にあった例：
A社ではAPIのロジックに対してすべて単体テストを実装。カバレッジは90%以上。しかし、実際にデプロイしたところ。
・外部APIからのレスポンス形式がドキュメントと異なっており → パースエラー
・DBのカラム名が手動で変更され → 保存失敗
単体テストでは外部の仕様変更を検出できなかった
5. 結合テストだけでは不十分な理由【実例】
B社では、エンドポイント単位で結合テストを構築し、DBと通信する統合テストを中心に運用。
しかし、
・一部のAPIロジックにバグが混入 → 特定の条件下でのみ発生
・結合テストでは網羅できず、ユーザーからの苦情で発覚
「細かいロジックミス」は結合テストでは見逃されやすい
6. 両方を組み合わせるメリットとは？
両者を組み合わせることで：
・ バグの発生率を大幅に減少
・ リファクタリングや仕様変更にも柔軟に対応
・ 開発チーム全体の信頼性と安心感が向上
7. テストピラミッドから見る理想的なバランス
「Test Pyramid（テストピラミッド）」とは、最も効率的なテスト構成比率を示す考え方です。
[ UIテスト ] → 少数
[ 結合テスト ] → 中程度
[ 単体テスト ] → 多めに
・ 単体テストで「バグの早期発見」
・ 結合テストで「全体の安定性を確認」
・ UIテストは必要最低限に（コストが高いため）
ポイントは「重複を避けつつ、補完し合う」ことです。
単体テストと結合テストは、それぞれが補完し合う存在であり、どちらか一方に偏ったテスト戦略では、システム全体の品質を十分に担保することはできません。単体テストによってコードレベルのバグを早期に検出し、結合テストによってコンポーネント間の連携や実環境に近い挙動を確認することで、より安定した信頼性の高いソフトウェアを提供できます。テストは「量より質」、そして「バランス」が何よりも重要です。今一度、自分たちのテスト戦略を見直し、継続的な改善を図っていきましょう。
