ウォーキングスケルトンE2E
同じ統合経路の代表を薄く保ち、独立した重要境界には必要な証拠を加える。
同じ統合経路の代表を1本から始める
外部サービス機能は端から端までの接続を証明する必要がありますが、すべての値・応答条件をブラウザで再演する必要はありません。同じ統合経路の代表として、タグなしでCIセーフな薄いジャーニー1本から始めます。例えば e2e/ です。
「1本」はシステム全体の永久上限でも、機能ごとに必ず追加する下限でもありません。独立した認証・アップロード・native境界には追加証拠が妥当な場合があります。同じ接続を通る組み合わせは下位層へ寄せ、別の重要経路は必要に応じて別の薄いテストで守ります。件数制限のために無関係な経路を巨大な1 specへ詰め込みません。
これはスイート全体の予算を狭い範囲で補完するパターンです。予算のページは、個々には安価なテストの集合でもゲートを溺れさせ得る理由を説明します。ウォーキングスケルトンは、そもそもその集合を作らせません。重いテストの判断ルールは個々の重いテストにティアを与える価値があるかを引き続き判断しますが、ウォーキングスケルトンはそれより前の問いを立てます。提案されたE2Eバリアントは、新しい統合配線を何か証明するのか。入力やレスポンス条件をもう1つ増やすだけなら、答えは「証明しない」です。
Note
タグなしであることも契約の一部です。 このジャーニーは通常のT1カバレッジであり、特別な @heavy やスケジュール実行用の標本ではありません。fakeを決定的に保ち、1つの証明がすべてのPRで走れる短さに経路を保ってください。
実例のジャーニー：すべての接合部に一度だけ触れる
ドキュメントクラウド連携を考えます。その単一のジャーニーは次の形です。
トークンを貼り付ける。 ユーザーが目にするものと同じ認証情報UIからテスト用トークンを入力します。トークンはアプリケーションの認証情報境界へ到達し、fakeは実シークレットを必要としません。
プロジェクト一覧を読み込む。 fakeサービスが返すプロジェクトを待ち、その1つを選びます。これにより、認証情報の状態、アダプター、最初のリモート読み取りの接続を証明します。
同じフレーム内でページタブを開く。 ページを選び、エディターフレームの安定した同一性を記録します。タブを開いたとき、密かに新しいブラウジングコンテキストへ置き換えるのではなく、そのフレームを再利用しなければなりません。
ページを編集する。 エディター画面から小さく明確なコンテンツ変更を加え、その間も同じフレームであることをアサートし続けます。
ガード付き保存を行う。 現在のリモートリビジョン、または同等の書き込みガードを付けて保存します。fakeなら無条件書き込みを受け入れられるという理由で、ジャーニーを弱めてはいけません。
トレースで再取得を検証する。 fakeサービスの秘匿化済みリクエストトレースを読み、ガード付き書き込みのあとに想定した再取得が行われたことをアサートします。UIが保存済みに見える状態へ到達しても、このリクエストが境界を越えた証明にはなりません。トレースは、貼り付けたトークンを露出させずに、実際にリクエストが起きたことを証明します。
公開する。 fakeが支える同じプロジェクトに通常の公開操作を行い、同じエディターフレームに留まります。
受付済み状態のチップを確認する。 安定したUI上の結果、つまり公開したリビジョンに受付済み状態のチップが表示されたところで完了します。
フレーム同一性のアサーションはセットアップ時の1回ではなく、ジャーニー全体にわたります。トークン貼り付け、一覧読み込み、タブ選択、編集、保存、再取得、公開、受付のすべてが、長く存続する同一フレームを通って行われなければなりません。アプリケーションが途中で誤ってフレームを再マウントしたり入れ替えたりしても、最後のチップだけは正しく見えることがあります。その一方で、メモリ上のエディター状態、購読、メッセージルーティングは失われているかもしれません。ウォーキングスケルトンが守るのは、最後のスクリーンショットだけでなく統合の接合部です。
ジャーニーのfakeは外部サービス境界に置き、アプリケーション自身のアダプターをモックで消すことなくリクエストを観測できるようにします。ステートフルfakeサービスのレシピを使い、一覧、ガード付き書き込み、再取得、公開、受付済み状態を、互いに無関係な缶詰レスポンスではなく、1つのサービス状態を順に観測したものにしてください。
トレースは証拠であり、別のUIアサーションではない
秘匿化済みリクエストトレースは、特定の偽陽性経路を閉じます。保存ハンドラーがローカル状態だけを楽観的に更新し、受付済みに見えるUIが現れても、ガード付きネットワークリクエストは欠落または不正なままかもしれません。同じUIに保存できたかを尋ねても、アプリケーション自身の主張を繰り返すだけです。
代わりに、境界の反対側からfakeを調べます。トレースエントリーは、契約に必要なリクエスト順序と非シークレットのガードメタデータを立証しなければなりません。ガード付き保存が到着し、選択したページを対象とし、アプリケーションが公開前に後続の再取得を行ったことです。トレースがテスト証拠になる前に秘匿化を行うため、アーティファクトを認証情報漏えいに変えずに認証情報処理を通せます。
このアサーションは狭く保ってください。トレースは、すべてのヘッダー、競合レスポンス、ペイロードの組み合わせをブラウザジャーニーで再現するための招待状ではありません。UIの結果だけでは自己同意になり得る1つの統合遷移に、独立した証拠を与えるものです。
すべてのマトリクスをE2Eより下へ置く
ウォーキングスケルトンが担当するのはトポロジーです。代表的な1操作が、必要な境界をすべて越え、観測可能な状態として戻ってこられるかを確かめます。幅を担当するのは、より安価なスイートです。
| 振る舞いのファミリー | 意図的な置き場所 | ジャーニーを延ばさない理由 |
|---|---|---|
| 競合マトリクス | リビジョンと競合ポリシーのユニットテスト、および競合表示ごとのコンポーネントテスト | 変化するのはガードと解決方法であり、統合トポロジーではない |
| SSE失敗ケース | パース、リトライ、順序、重複排除のユニットテスト、および切断・復旧状態のコンポーネントテスト | イベントの欠落、重複、不正形式は状態機械の分岐であり、別の完全なユーザージャーニーではない |
| サニタイザーケース | 悪意ある入力と不正入力の完全なコーパスを使うユニットテスト | ブラウザのセットアップを加えても、変換契約の証明は強くならない |
| 認証情報処理 | 保存、秘匿化、期限切れ、拒否のユニットテスト、および認証情報UI状態のコンポーネントテスト | スケルトンが1つの安全なテスト用トークンを貼るのは配線の証明だけが目的であり、認証情報マトリクスにしてはいけない |
重要なバリアントでも、この分割は変わりません。重要であることはE2Eであることを意味しません。競合ポリシーには数十ケースの価値があっても、追加のブラウザジャーニーはゼロで構いません。重いテストの判断ルールは、保証を対応づけてから下位層へ移すよう求めています。ここでの降格は、E2Eスイートが遅くなってから行う救出ではなく、あらかじめ計画したアーキテクチャです。
Warning
新しい分岐をカバーするために、ウォーキングスケルトンへ「あと1ステップだけ」を追加しないでください。本当により良い代表経路になるステップなら、古い代表を置き換えます。横に積み上げるのではありません。同じ接合部を通るバリアントは、ユニットまたはコンポーネントカバレッジへ移します。
コントリビューターの目に入る場所へ境界を書く
割り当ては計画issueやレビュアーの記憶に残すのではなく、スイートの隣 — たとえば e2e/ — に置きます。その記述では、契約の3つの部分をすべて名指ししてください。
e2e/は、この統合経路を代表するタグなしE2Eスペックであり、トークン → 一覧 → 同一フレームでの編集 → ガード付き保存／再取得 → 公開 → 受付済み状態を歩く。doc- cloud- walking- skeleton. spec. ts 競合マトリクス、SSE失敗、サニタイザーケース、認証情報バリアントは、名指ししたユニット／コンポーネントスイートの場所に置く。
E2Eステップまたはバリアントを追加する提案は、既存の代表経路を置き換えるか、本当に新しい統合の接合部を説明しなければならない。「重要な振る舞い」であることだけでは不十分。
このローカルな記録は、口頭の慣習が通用しない2つの場面を越えて残ります。カバレッジの追加場所を探す新しいコントリビューターと、見えているファイルからポリシーを推測する新しいエージェントセッションです。READMEは、存在しないことを強制可能な設計判断へ変えます。これがなければ、スペックが1つしかない状態は単なる未完成に見えてしまいます。
構造が同じ範囲で増殖を抑える
同じ配線の値・状態の組み合わせには、より安価なスイートを増やします。独立した重要境界が増えれば統合テストと費用も増え得ます。T1費用が永久に一定とは約束しません。ライフサイクルに沿って必要な契約を維持し、スイート予算で実測します。