テスト戦略
🎯 目的
idp-serverの品質を継続的に担保し、安全かつ信頼性の高い機能提供を実現するためのテスト戦略を定義する。
このドキュメントでは、E2Eテストとパフォーマンステストを中心に、現状の方針や考え方、将来的な展望を含めて記載する。
🧭 戦略方針（Strategic Focus）
E2E重視の戦略
idp-serverは現在、E2Eテスト重視のテスト戦略を採用している。
単体レベルはコード単体の正しさは実装で保証し、プロトコルフロー全体が期待どおりに動作することを最優先としている。
ユニットテストよりE2Eを優先している理由
- 仕様準拠が最優先：OAuth / OIDC / FAPI / CIBA などのプロトコルに準拠して正しく動作することが、idp-serverにおいて最も重要な価値と位置づけている。
- 全体としての動作確認が本質：個々のメソッドの正当性に動くだけの保証よりも、テナント、クライアント、認証、ポリシーなどの構成要素が連携したときに期待通りに動作するかを重視している。
- 堅牢な設計による補完：ロジック層は各クラスの責任範囲が明確で、コードレベルの安全性を担保しやすい構造になっている。
idp-serverの戦略はAPIとして、「動く保証」を第一にしている。ユニットテストは設計品質で支える。
今後のテスト拡充ポイント
一方で今後は、コアロジックから優先しユニットテストの拡充を検討している。
- バリデーション
- 認証ポリシー
- 拡張ポイント（Hook、Authenticatorなど）
🧪 E2Eテスト
目的
プロトコル全体の一連のフローが、正しく相互作用しながら動作することを確認する。
対象範囲
- Authorization Code Flow（PKCE含む）
- Federation認証（email, SMS認証）
- CIBA（Push / Ping / Poll）
- MFA登録・認証
- 身元確認申請・完了処理
- 管理API経由の設定
テスト構成
-
📘
scenario/: 現実的なユーザー操作やシステム動作を再現するシナリオテストを格納。- 例：ユーザー登録、SSOログイン、CIBAフロー、MFA登録など
-
📕
spec/: 各種仕様（OpenID Connect, FAPI, JARM, Verifiable Credentials）に基づく準拠性テストを格納。- OIDCのクレーム検証や、JARMレスポンス構造チェックなどを実施
-
🐒
monkey/: 故意に異常値やプロトコル違反を注入して、実装の堅牢性を検証。- 不正なパラメータ、不正順序、失敗時リトライ処理などを対象
📈 パフォーマンステスト
目的
同時アクセス や高負荷下における応答性能・スループットを確認する。
テストの種類
idp-serverの信頼性とスケーラビリティを検証するため、以下のパフォーマンステストを実施する：
| 種類 | 説明 |
|---|---|
| ✅ 負荷テスト（Load） | 期待される通常負荷（例：500 RPS）の下で、システムがどの程度持続的に処理できるかを測定。主に定常状態の性能に着目。 |
| ✅ ストレステスト（Stress） | 想定を超える高負荷を与えて、エラー発生率やシステムの劣化挙動を観察。リミット突破後の耐性を見る。 |
| スパイクテスト（Spike） | 瞬間的な大量アクセス（例：0→1000 RPS）に対する急激な負荷耐性を確認。 |
| ソークテスト（Soak） | 通常負荷を長時間（例：1時間以上）継続し、メモリリーク・GC問題・長期劣化を検出。 |