E2Eテストとは？利用者の操作を端から端まで確かめる

Appli Parkでは、CMSで公開中の記事を直すとき、下書きを保存したあとにプレビューを開き、公開ページが元の内容のままかも手動で確認しています。「保存できた」と表示されるだけでなく、編集内容が残り、読者に見える記事は変わらないところまで確かめる作業です。この身近な操作を出発点に、「保存処理のテストと、画面から一連の操作を確かめるテストは何が違うのだろう？」という疑問を整理してみます。今回取り上げるのは、利用者の操作を端から端まで確かめるE2Eテストです。 E2EはEnd-to-Endの略です。画面を開き、入力し、保存し、開き直す。そこまでを一つの利用体験として確かめます。この記事では、Appli Parkで行っている手動確認、既存の自動テスト、自動E2Eの将来案を分けて紹介します。

現在、手動で確認している「下書き保存」の流れ

現在の手順は「公開中の記事を編集する→下書きを保存する→下書きプレビューに変更が出る→公開ページは変わらない→編集画面を開き直して保存値が残る」です。保存APIだけのテストでは見つけにくい、画面の入力状態、下書きAPI、認証、データベース、プレビュー表示のつなぎ目を確認します。

既存テストと手動確認の役割分担

リポジトリには、フロントエンドの関数テスト、バックエンドのサービス・認可テスト、インフラのCMSルーティングテストがあります。ArticleServiceTestsでは下書き保存や公開反映の処理を細かく確認できますが、実際の管理画面で入力してプレビューを開くところまでは通りません。そこで現在は、ロジックを既存の自動テスト、画面から表示までの一連の流れを手動確認に分けています。

自動化する場合の設計案

将来Playwrightで自動化するなら、固定の待ち時間やCSSクラスではなく、利用者に見えるラベル・見出し・保存完了状態を使います。Playwright公式も利用者に見える挙動、テストの分離、ユーザー向け属性を優先したロケーターを勧めています。テスト専用の記事と環境を分け、他のテストが残した下書きに依存しない構成が前提です。これは現在の実装コードではなく、公式資料と現行CMSの操作から整理した設計案です。

手動確認の実例：下書きと公開版を見比べる

今回のような公開中記事の修正では、タイトル・概要・本文を変更して「下書きを保存」し、専用プレビューで変更後の見出しと画像を確認します。同時に公開ページを開き、公開タイトルと本文が従来のままであることを確かめます。最後に編集画面を開き直し、「保存済みの編集下書きがあります」と表示され、入力値が残っていることを確認します。「変更を公開」は手動確認に含めません。公開事故を避けるため、下書きの確認と公開判断を別にします。

現在の制約：自動E2Eテスト群はまだ整備途中

自動化する場合の候補は、入力、保存完了、下書きプレビュー、公開ページ、再編集後の保存値を一つずつ確かめるシナリオです。ただし現在のAppli Parkには、この経路を継続実行するE2Eスイートはありません。まずテスト専用データと実行環境を分離し、本番記事を変更しない境界を決めてから導入します。現時点では、単体・サービス・認可・インフラテストで守れている範囲と、手動で確認している範囲を分けて管理しています。