Playwrightの公式並行テストガイドでは、テストファイルは既定で並行実行され、同じファイル内のテストは通常同じworker内で順に実行されます。公式ガイドが示すこの実行単位を踏まえ、共有アカウントや受信資源に同じ名前のテストロックを使ってください。ロックは資源の同時利用を抑えますが、読んだメールが現在のテストのものかは判定しません。固有のテスト識別子か隔離された受信先も用意しましょう。
このガイドの対象
複数ファイルやprojectを並行実行し、共有受信資源の競合を疑っている開発者。
登録・認証メールを検証するQA担当者と、CIテスト環境を保守するエンジニア。
最終確認日：2026年10月24日。Playwrightのリリースノート、並行テストガイド、Test APIを確認しています。ロックの書式や適用範囲は変更される可能性があるため、実装時にはプロジェクトにインストールされたバージョンの公式資料も確認してください。
実行前：共有しているものを洗い出す
まず、並行するテストが共通で使うものを特定します。対象は、受信箱、テストアカウント、メール取得用のAPIやフィクスチャ、テスト後のメール削除処理などです。複数のテストが同じアカウントの状態を変更したり、同じ受信箱からメールを取得・削除したりするなら、競合する可能性があります。
ただし、失敗の原因をすべて並行実行に結び付けるのは避けてください。メール送信自体の失敗、メールの遅延、古いメールの残存、テストデータの不整合でも同様の症状が起こります。まず「共有資源への同時アクセスを止めたい」のか、「取得したメールが現在の実行に属することを確かめたい」のかを分けます。
テストデータやメールに実在の個人情報を使っている場合は、識別子を加えるだけでなく、データの扱いも見直しましょう。テストデータのライフサイクルを確認し、不要になった情報の保管や削除もテスト設計に含めてください。
設定前：ロック名を共有資源に合わせる
ロック名はテスト名ではなく、競合を避けたい共有資源の単位で決めます。同じテストアカウントを使う複数のテストなら同じ名前にし、別の受信箱を使うテストまで一律に同じロックへ入れないようにします。無関係なテストを同じロックでまとめると、不要な待ちが生じます。
Playwrightのテストロックと、受信箱そのものが持つ隔離機能は別物です。ロックはPlaywrightのテスト実行側で用例同士のアクセスを調整しますが、受信先のメールを識別したり、他のプロセスや独立したCI実行まで調整したりするとは限りません。
| 状況 | ロック名の考え方 | 確認すること |
|---|---|---|
| 複数テストが同じテストアカウントを変更する | そのアカウントを表す共通名 | 状態変更や後処理も同じ資源を使うか |
| 複数テストが同じ受信箱を読む・消去する | 受信箱を表す共通名 | 読み取りと清掃の両方が調整対象か |
| テストごとに独立した受信先を使う | 不要な共有ロックを避ける | 本当に共有資源がないか |
| 複数のテストランナーやCIジョブが同じ資源を使う | Playwright内のロックだけに依存しない | プロセス間の調整手段が別に必要か |
正確なAPIの書式は、導入済みバージョンのTest APIで確認してください。テスト単位で指定する場合と、describeグループに適用する場合とで、意図した範囲にロックがかかっているかを確かめます。サンプルを別バージョンの資料からそのまま移すのではなく、実際のプロジェクトで解釈される構文を使ってください。
実行時：競合するテストだけを相互排他にする
同じテストアカウントや受信箱を使うテストには、同じ名前のロックを適用します。こうすると、同じロックを宣言した用例は共有資源へのアクセスが重ならないよう調整され、別の資源を使うテストは並行実行を続けられます。共有受信箱を使う一部のテストのために、テスト全体を無条件に直列化する必要はありません。
ロックをテスト単位で付けるか、describeグループに付けるかは、資源を共有する範囲で決めます。設定の範囲が広すぎればテスト時間を余計に増やし、狭すぎればロック対象外のテストが同じ資源へアクセスします。既定の実行方法、直列実行、並行実行の設定も合わせて確認し、宣言したロックが対象テストを本当に覆うか、実行ログで確かめましょう。
ロック名の一致だけで、すべてのテスト環境が相互に調整されるとは限りません。プロジェクトやテストランナーの構成、Playwrightのバージョンを確認し、同じテスト実行の範囲内で有効かを検証してください。
メール到着後：現在のテストとの対応を検証する
ロックによって同時アクセスを避けても、受信箱には前回の実行で届いたメールが残ることがあります。メール取得処理が最初に見つけた検証メールを選ぶだけでは、別のテストのコードや古いリンクを誤って使うおそれがあります。メールの到着そのものと、そのメールが今のテストに属することは別々に検証してください。
自社製品のテストメールに、実行やテストを区別できる識別子を含めます。たとえば、テスト情報から取得できる識別用の値をメールの件名・本文や登録データに対応付け、取得後に一致を確認します。TestInfo APIで利用可能なテスト情報を確認し、リトライ時も初回実行と区別できる証跡を残してください。検証コードやリンクが、現在のテストで作成したユーザーと期待する状態に対応しているかもアサートします。
再実行時：リトライと清掃の競合を確かめる
失敗後のリトライでは、初回実行のテストアカウント状態、受信箱に残ったメール、テスト後の削除処理を確認します。初回に送信されたメールをリトライが拾うなら、ロックがあっても誤ったテスト結果につながります。実行ごとに変わる識別子を使い、古いメールを除外できる条件を設けてください。
清掃処理も共有資源を使うテストの一部です。あるテストが受信箱を空にしている間に、別のテストがメールを取得すれば、検証対象が消える場合があります。削除や初期化を行うテストにも適切なロックを適用するか、テストごとに受信先を分けるかを決めます。Playwrightのリトライに関する資料を確認し、初回と再試行の結果、取得したメールの識別情報、失敗したアサーションをログに残しましょう。
完了時：ロックを残すか、受信資源を分けるか
次の条件分岐で、テスト設計を決めます。
- 共有資源への同時アクセスが原因と確認でき、同じPlaywright実行内で調整できる場合：対象のテストだけに共通の命名ロックを適用し、どの資源を守るロックかを記録します。
- 同じ受信箱でもメールの所有を識別できる場合：ロックに加えて実行ごとの識別子を使い、古いメールや他のテストのメールを除外します。
- メールの所属を証明できない、またはリトライで古いメールを拾う場合：テストごとの受信先や専用アカウントに切り替えます。
- 独立したプロセスやCIジョブも同じ資源にアクセスする場合：Playwright内のロックを唯一の調整手段にせず、別の共有管理方法か独立した受信資源を選びます。
| 選択肢 | 向いている条件 | 残る確認事項 |
|---|---|---|
| 命名ロック | 同じPlaywright実行内のテスト同士が共有資源を競合利用する | メールの所属と、別プロセスのアクセス |
| 識別子付きの共有受信箱 | メールに実行・テストごとの識別情報を付けられる | 古いメールの除外と、識別子の照合 |
| 独立したアカウント・受信先 | ロックや識別子だけでは取り違えを防げない | アカウント作成・清掃の運用 |
| メール取得を伴わない検証 | テスト対象の確認に実メールが必要ない | 実際の受信経路を検証できない範囲 |
命名ロックが調整するのは、同じテスト実行内で同じロック名を宣言する用例の共有資源アクセスです。メールの受信や正しい検証コードの選択を保証するものではありません。実メールを検証するテストでは、ロック、メールとの関連付け、受信の証拠を別々に確認します。
よくある判断
Playwrightのテストロックで、別ファイルのテストも調整できますか？
同じロック名を宣言したテストを、同じPlaywright実行内で調整できるかは、導入バージョンのロックAPIとテスト構成を確認して判断します。複数ファイルやprojectをまたぐ場合も、名前だけで適用範囲を推測せず、公式API資料と実際の実行結果を照合してください。独立した起動プロセスやCIジョブは別に検討します。
ロックを使えば、検証コードメールの取り違えはなくなりますか？
ロックは共有資源への競合を抑えるもので、取得したメールが現在のテストに属するかは判定しません。テスト固有の識別子をメールと登録データに対応付け、その一致を検証してください。メールの到着時刻だけに頼る方法では、古いメールや別テストのメールを見分けられません。
共有受信箱から専用の受信先へ切り替える目安は何ですか？
メールに実行ごとの識別情報を加えても所属を判定できない場合や、テストの清掃・再試行が他の用例に影響する場合は、独立した受信先やテストアカウントを検討してください。複数のプロセスが受信箱を使う場合も、Playwrightのテストロックだけで調整できるかを先に確認します。
実メールを使わない方法に切り替えるべきですか？
検証対象が画面表示やアプリ内部の状態で、メールの配送経路を確認する必要がないなら、実メールを読む工程を分離できる場合があります。一方、登録確認や通知メールの送信・受信そのものを検証するテストでは、受信の証拠が必要です。何を保証するテストなのかに合わせて選んでください。
自社製品の登録や通知メールを実際に受信して確かめる必要があるなら、テスト専用の受信先を用意する方法もあります。MaskSendの一時メールを候補にする場合は、導入前に受信方法やメールの保持条件がテスト要件に合うかをサービス案内で確認してください。長期的なアカウント復旧や継続受信が必要な用途には、一時メールではなく管理可能な専用アドレスを使うのが適切です。
よくある質問
Playwrightのテストロックを使えば、並行テストが別の検証コードを読むのを防げますか？
同じ名前のロックを共有するテスト同士が、同じ共有資源を同時に使う競合は抑えられます。ただし、ロックは受信メールの所有者を判定しません。テスト固有の識別子をメールに含め、現在の実行に合うコードかを別途検証してください。
複数のテストファイルやprojectで命名ロックを共有するには、何を確認すればよいですか？
各テストが同じロック名を宣言し、同じPlaywrightのテスト実行内でロック機構の対象になる構成かを確認します。APIの書式と適用範囲は、導入済みPlaywrightのバージョンに対応する公式資料で照合してください。独立して起動したCIジョブまで共有されるとは考えないでください。
共有受信箱で、届いたメールが今のテスト実行のものかどうかはどう確かめますか？
メールの件名や本文、登録データなどに実行ごとの識別子を含め、読み取ったメールが現在のテスト識別子に一致することをアサートします。メールの到着時刻だけでは、古いメールや別テストのメールを排除できません。検証コードやリンクも現在のテスト状態と照合してください。
どの段階で共有受信箱ではなく、専用アカウントや受信先に切り替えるべきですか？
ロックを使っても古いメールとの判別ができない場合や、テストごとのメール所有を証明できない場合は、受信先またはテストアカウントを分けてください。別のプロセスやCIジョブも同じ受信箱を操作する場合も、Playwright内のロックだけでは調整できません。
今すぐ受信テスト
短期登録には使い捨てメールボックスを、長期的なやり取りには独立した転送エイリアスを。信頼できる相手との通信には、普段のメールアドレスを使いましょう。