スロット攻略 プロジェクトドキュメント

Appearance

会員登録 シナリオテスト手順 ​

会員登録からメール確認・ログイン・マイページまでの通しフローを手動で確認するための手順です。 対象は登録フォーム、確認メール、メール認証、ログイン、バリデーション分岐です。

対象範囲 ​

  • 非会員が /member-register/ から無料会員登録できる
  • 登録成功後は自動ログインせず /member-login/?registered=1 へ遷移し、確認メール案内が表示される
  • 確認メール内リンク（/member-verify-email/?uid=&token=）でメール認証が完了する
  • 認証後にログインするとマイページ（/member-mypage/）へ遷移する
  • 不正入力・重複メール／表示名・ログイン済みアクセス・無効／期限切れトークン・再送が想定どおりになる
  • メール未認証でもログイン自体は可能だが、有料記事購入はゲートされる（詳細は有料記事手順へ委譲）

有料記事の単号購入・Stripe Checkout は本手順の対象外。有料記事決済 シナリオテスト手順 を参照する。

テスト対象の設計書 ​

本手順が検証する仕様の正本:

前提 ​

  • Local または Staging で実施する。本番ユーザー・本番メールアドレスでは実施しない。
  • 会員固定ページ（member-register / member-login / member-verify-email / member-mypage）が作成済みであること（MemberPagesInstaller により初回起動時に自動作成される）。
  • 確認メールを受信できること。ローカルでは MailHog などのメール捕捉環境、または wp_mail の送信ログで確認する。
  • テストには未使用のメールアドレスと表示名を使う。既存会員と衝突しないこと。
  • DB やユーザー meta を直接更新する場合は、事前にローカル環境またはステージング環境で行う。本番 DB では事前バックアップを取る。

事前準備 ​

1. テスト用メール・表示名を決める ​

例:

  • メール: scenario-register-<YYYYMMDDHHMM>@example.test
  • 表示名: シナリオ登録_<YYYYMMDDHHMM>
  • パスワード: 8 文字以上（例: TestPass1!）

2. メール受信環境を確認する ​

ローカル:

  • MailHog 等で SMTP を受けられること
  • 件名「【スロット攻略】メールアドレスの確認」が届くこと

ステージング:

  • テスト用メールアドレスで実受信できること

3. 既存ユーザーと衝突しないことを確認する ​

WP-CLI が使える場合:

bash
wp user list --search='scenario-register-' --fields=ID,user_email,display_name,roles

同メール／同表示名が既にある場合は別名にするか、テスト専用ユーザーを削除してから実施する。

4. ログイン済みセッションを切る ​

登録画面の確認は非ログイン状態で行う。ブラウザのシークレットウィンドウを使うか、ログアウトする。

5. 登録レート制限に注意する ​

登録 POST には IP 単位で 2 系統のレート制限がある。超過時のメッセージは「同一IPからのリクエスト上限に達しました。しばらく時間をおいてから再度お試しください。」。

系統Transient キー接頭辞上限カウントタイミング
登録失敗member_register_ip_3 回／1 時間バリデーション失敗などを含む失敗 POST
登録成功member_register_success_ip_10 回／1 時間登録成功時（失敗カウンタは成功時にリセット）

手動で失敗送信を繰り返す前、または短時間に多数の正常登録を試す前に、必要なら次で transient を消す（<client_ip> はブラウザがサイトへ届く IP。Local では多くの場合 127.0.0.1）。

bash
# 失敗カウンタ: member_register_ip_ + md5(IP)
wp transient delete member_register_ip_$(php -r "echo md5('127.0.0.1');")

# 成功カウンタ: member_register_success_ip_ + md5(IP)
wp transient delete member_register_success_ip_$(php -r "echo md5('127.0.0.1');")

手動シナリオ ​

S1. 正常登録 → 確認メール → 認証 → ログイン → マイページ ​

前提: 登録成功レート制限に余裕があること（同一 IP から短時間に 10 件超の成功登録を続けると制限に抵触する。必要なら事前準備「5」で成功 transient を削除）。

  1. シークレットウィンドウで /member-register/ を開く。
  2. メール・パスワード・パスワード確認・表示名を入力し、利用規約・プライバシーポリシーに同意して送信する。
  3. /member-login/?registered=1 へリダイレクトされることを確認する。
  4. 案内文「ご登録ありがとうございます。確認メールを送信しました。メール内のリンクをクリックして確認後、ログインしてください。」が表示されることを確認する。
  5. この時点ではまだログインしていないこと（マイページに入れない／ログインフォームが表示される）を確認する。
  6. 受信トレイ（または MailHog）で件名「【スロット攻略】メールアドレスの確認」を開く。
  7. 本文のリンク（/member-verify-email/?uid=...&token=...）をクリックする。
  8. /member-login/?verified=1 へリダイレクトされ、「メールアドレスの確認が完了しました。ログインしてご利用ください。」が表示されることを確認する。
  9. 登録したメールとパスワードでログインする。
  10. /member-mypage/ へ遷移することを確認する。

期待結果:

  • WordPress ユーザーが作成され、ロールは member。
  • member_email_verified が確認後に 1 になる。
  • member_terms_accepted_version / member_terms_accepted_at が記録されている。
  • member_privacy_policy_accepted_version / member_privacy_policy_accepted_at / member_terms_consent_source / member_terms_consent_terms_url / member_terms_consent_privacy_policy_url / member_terms_consent_terms_hash / member_terms_consent_privacy_policy_hash が記録されている。
  • 通常のブラウザ登録では member_terms_consent_ip / member_terms_consent_user_agent が記録されている。
  • 自動ログインは行われない（登録直後はログイン画面）。

確認例（WP-CLI）:

bash
wp user get <user_id> --fields=ID,user_email,display_name,roles
wp user meta get <user_id> member_email_verified
wp user meta get <user_id> member_terms_accepted_version
wp user meta get <user_id> member_terms_accepted_at
wp user meta get <user_id> member_privacy_policy_accepted_version
wp user meta get <user_id> member_privacy_policy_accepted_at
wp user meta get <user_id> member_terms_consent_source
wp user meta get <user_id> member_terms_consent_ip
wp user meta get <user_id> member_terms_consent_user_agent
wp user meta get <user_id> member_terms_consent_terms_url
wp user meta get <user_id> member_terms_consent_privacy_policy_url
wp user meta get <user_id> member_terms_consent_terms_hash
wp user meta get <user_id> member_terms_consent_privacy_policy_hash

S2. バリデーションエラーと入力保持 ​

フィールド別の拒否ロジックは PHPUnit（MemberRegisterServiceTest の test_register_rejects_*）で担保済み。手動は スモークとして 1〜2 ケースに絞る（例: 不正メールと規約未同意）。全 5 ケースを連続で試すと、失敗送信がレート制限（3 回／1 時間）に抵触し、4 ケース目以降はフィールドエラーではなくレート制限メッセージになる。

追加で別ケースを試す場合は、ケース間で事前準備「5. 登録レート制限」の transient 削除を行う。

ケース（例）操作期待メッセージ
不正メールメールを not-an-email にする有効なメールアドレスを入力してください。
規約未同意チェックを外す利用規約およびプライバシーポリシーへの同意が必要です。

（参考・手動必須ではない）短パスワード／パスワード不一致／表示名空の期待文言は MemberRegisterCopy および PHPUnit 対応表を参照。

期待結果:

  • ユーザーは作成されない。
  • メール・表示名・規約チェック（チェック済みの場合）は再表示される（old_input）。
  • パスワード欄は再表示されない（空のまま）。

S3. 既存メールで登録拒否 ​

前提: 登録レート制限に余裕があること（必要なら事前準備「5」で transient を削除）。S2 の直後に続ける場合は必ずクリアする。

  1. S1 で作成済みのメール、または既存会員のメールを使う。
  2. 別の表示名・有効なパスワードで /member-register/ から送信する。

期待結果:

  • 「このメールアドレスは既に登録されています。」が表示される。
  • 新規ユーザーは作成されない。

S4. 既存表示名で登録拒否 ​

前提: 登録レート制限に余裕があること（S3 と同様）。

  1. S1 で使った表示名、または既存会員の表示名を使う。
  2. 未使用のメール・有効なパスワードで送信する。

期待結果:

  • 「この表示名は既に使用されています。別の表示名を入力してください。」が表示される。
  • 新規ユーザーは作成されない。

S5. ログイン済みで登録画面へアクセスするとトップへリダイレクト ​

  1. テスト会員でログインする。
  2. /member-register/ を開く。

期待結果:

  • 登録フォームは表示されない。
  • サイトトップ（/）へリダイレクトされる（MemberRegisterConstants::build_logged_in_redirect_url()）。

S6. 認証トークン不正／期限切れ ​

前提: 確認 URL の uid がログイン中ユーザーと一致する場合は検証結果（無効・期限切れ）が表示される。他人の uid のリンクをログイン中に開くとサイトトップへリダイレクトされる。未ログインでも同様に無効・期限切れメッセージが出る。

S6a. 不正トークン ​

  1. 未認証のテスト会員を用意する（S1 の登録直後、または meta で未確認に戻す）。
  2. /member-verify-email/?uid=<user_id>&token=invalidtoken を開く（未ログイン、または当該ユーザーでログイン中）。

期待結果:

  • 「確認リンクが無効です。下記フォームから確認メールの再送をリクエストしてください。」が表示される。
  • member_email_verified は 1 にならない。

S6b. 期限切れトークン ​

  1. 登録直後など、確認メール本文に載っている平文 token を控える（meta member_email_verify_token はハッシュのみのため、平文はメール／URL から取得する）。
  2. 未認証ユーザーのトークン有効期限を過去にする。
bash
wp user meta update <user_id> member_email_verify_expires_at "1000000000"
  1. 手順 1 で控えた正しい token で確認 URL を開く。

期待結果:

  • 「確認リンクの有効期限が切れています。下記フォームから確認メールの再送をリクエストしてください。」が表示される。
  • member_email_verified は 1 にならない。

S7. 認証メール再送後に有効リンクで成功 ​

  1. 未認証のテスト会員を用意する（S6 の状態のままでも可）。
  2. ログアウトした状態で /member-verify-email/ の再送フォームに登録メールを入力して送信する（email_not_verified なしでログイン済みだと確認画面はトップへリダイレクトされる）。
  3. 「登録済みかつ未確認の場合、確認メールを送信しました。」が表示されることを確認する。
  4. 新しい確認メールを開き、リンクをクリックする（未ログインなら /member-login/?verified=1、当該ユーザーでログイン中なら /member-profile/?verified=1 へ遷移する）。

期待結果:

  • 新トークンで認証が成功する。
  • member_email_verified が 1 になる。
  • 古いリンクは無効になる（再送でトークンが差し替わるため）。

補足:

  • 存在しないメールや既に確認済みのメールでも、同じ汎用メッセージになり、ユーザー存在有無を漏らさない。

S8. メール未認証でもログイン可能／購入はゲート ​

  1. 新規登録直後（メール未確認）のユーザーで /member-login/ からログインする。
  2. マイページ等に入れることを確認する（ログイン自体は拒否されない）。
  3. 公開済み有料記事の購入ボタンを押す（または 有料記事決済 シナリオテスト手順 の S3 を実施する）。

期待結果:

  • ログインは成功する。
  • Stripe Checkout へは遷移しない。購入履歴は増えない。
  • Checkout 開始処理は /member-verify-email/?email_not_verified=1 へリダイレクトする（PaidArticleCheckoutController → build_email_not_verified_url()）。
  • 着地後の MemberEmailVerificationController は、ログイン済みでも email_not_verified=1 のときは案内文 EMAIL_NOT_VERIFIED_INFO と再送フォームを表示する（MemberEmailVerificationControllerTest::test_render_shows_email_not_verified_info_for_logged_in_redirect）。

手動以外の確認方法 ​

1. PHPUnit の関連テストだけ実行する ​

登録・メール確認・ログインの分岐はユニットテストで確認できる。

bash
composer test -- --filter 'MemberRegisterServiceTest|MemberRegisterControllerTest|MemberEmailVerificationServiceTest|MemberEmailVerificationControllerTest|MemberLoginServiceTest|MemberLoginControllerTest'

環境によってテストコマンド名が違う場合は PHPUnit実行ガイド を参照する。

受け入れ条件と自動テスト対応 ​

受け入れ条件確認する PHPUnit
登録成功で member ロールのユーザーを作成するMemberRegisterServiceTest::test_register_creates_member_user / test_register_passes_member_role_to_wp_insert_user
不正メール・短パスワード・不一致・表示名・規約を拒否するMemberRegisterServiceTest の各 test_register_rejects_*
既存メール／既存表示名を拒否するMemberRegisterServiceTest::test_register_rejects_existing_email / test_register_rejects_duplicate_display_name
成功時にログイン URL（registered=1）へリダイレクトするMemberRegisterControllerTest::test_handle_request_redirects_after_successful_registration
ログイン済みは登録画面からリダイレクトするMemberRegisterControllerTest::test_handle_request_redirects_when_logged_in
失敗レート制限超過時にエラーを出すMemberRegisterControllerTest::test_handle_request_shows_rate_limit_message
成功レート制限超過時にエラーを出すMemberRegisterControllerTest::test_handle_request_shows_rate_limit_message_when_success_limit_exceeded
失敗制限と成功制限が独立しているMemberRegisterControllerTest::test_handle_request_success_limit_is_independent_of_failure_limit
有効トークンでメール確認できるMemberEmailVerificationServiceTest::test_verify_succeeds_with_valid_token
不正／期限切れトークンを拒否するMemberEmailVerificationServiceTest::test_verify_returns_invalid_for_mismatched_token / test_verify_returns_expired_for_past_expiry
再送は未確認ユーザーにのみ発行するMemberEmailVerificationServiceTest::test_resend_by_email_*
コントローラが成功／不正／期限切れ／再送を表示するMemberEmailVerificationControllerTest の各 test_render_* / test_handle_request_resends_email_on_valid_post
ログイン成功・空入力拒否・退会済み拒否MemberLoginServiceTest の各 test_login_*
登録完了後の registered=1 案内表示MemberLoginControllerTest::test_render_shows_registration_success_info_on_registered_redirect
ログイン成功後のデフォルト遷移先（/member-mypage/）MemberLoginControllerTest::test_handle_request_redirects_to_mypage_after_successful_login_without_redirect_to
未認証ユーザーの購入ゲート案内表示MemberEmailVerificationControllerTest::test_render_shows_email_not_verified_info_for_logged_in_redirect

実装参照:

  • App\Controller\member_register_controller\MemberRegisterController
  • App\Service\member_register_service\MemberRegisterService
  • App\Service\member_email_verification_service\MemberEmailVerificationService
  • App\Controller\member_email_verification_controller\MemberEmailVerificationController
  • App\Service\member_login_service\MemberLoginService

2. メール確認状態だけ WP-CLI で切り替える ​

UI を通さず購入ゲート等を確認する場合:

bash
wp user meta update <user_id> member_email_verified 0
wp user meta update <user_id> member_email_verified 1

3. ブラウザ E2E ​

会員登録の主要成功パス（登録フォーム → registered=1 案内 → メール確認トークンのハッシュ保存／同意証跡 meta → 確認 URL → verified=1）は tests/e2e/member-registration.spec.js で Playwright 自動化している。Local での実行は Playwright E2E 実行ガイド の npm run test:e2e:member-registration を参照。失敗系・レート制限境界などの網羅は本手動手順と PHPUnit を正とする。

片付け ​

テスト後は作成したユーザーを削除する。

bash
wp user delete <user_id> --yes

メール未達や途中失敗でユーザーだけ残っている場合も同様に削除する。S1〜S8 で複数ユーザーを作った場合は、テスト用メール検索で洗い出す。

bash
wp user list --search='scenario-register-' --fields=ID,user_email,display_name

レート制限 transient が残って再試行できない場合は、事前準備「5. 登録レート制限」のコマンドで削除する。

bash
# 登録失敗カウンタ（IP = 127.0.0.1 の例）
wp transient delete member_register_ip_$(php -r "echo md5('127.0.0.1');")

# 登録成功カウンタ
wp transient delete member_register_success_ip_$(php -r "echo md5('127.0.0.1');")

# 確認メール再送カウンタも同様（キー接頭辞が異なる）
wp transient delete member_email_verify_resend_ip_$(php -r "echo md5('127.0.0.1');")

wp transient delete --all はサイト全体の transient を消すため、Local の専用環境以外では使わない。

参考 ​