revenuecat-testing

RevenueCat のテスト

RevenueCat の統合がリリース前に正しく機能することを、開発者が体系的に検証できるようにします。「RevenueCat を追加したけれど、本当に動作しているのか？」という疑問を、具体的で確認可能な QA 計画に変えます。ユースケースの完全な一覧、検証方法、プラットフォームごとの差異、各ケースで確認できるシグナルは、references/use_cases.md に記載されています。正確なイベント名と前提条件については、こちらを参照してください。このファイルは運用ガイドです。

基本原則： RevenueCat のすべての動作には、確認可能なシグナルがあります。具体的には、特定のダッシュボードイベント（INITIAL_PURCHASE、TRANSFER、EXPIRATION、PRODUCT_CHANGE、CANCELLATION）、period_type の値、または CustomerInfo／デバッグログの状態です。テストで確認するのは「アプリがクラッシュしなかったか」ではなく、「期待するイベントが、正しいフィールドとともに顧客の履歴に表示されたか」です。必ずテストをシグナルに結び付けてください。そうでなければ、実際には何もテストしていません。

このスキルの使い方

1. セットアップ情報を確認します：対象のプラットフォーム（iOS／Android／クロスプラットフォーム／ウェブ課金）、SDK（ネイティブ、RN、Flutter など）、デバッグログとサンドボックスアカウントを有効にしているか、具体的に何を検証したいのか、または何が壊れていると考えているのかを確認します。
2. まず前提条件を整えます — 「購入が機能しない」という報告の多くは、購入フローを試す前に確認できる設定の問題です。
   • configure() の前にデバッグログを有効にし（iOS では Purchases.logLevel = .debug、Android では setLogLevel(LogLevel.DEBUG)）、**「Invalid Product Identifiers」**とエラーレベルのログを確認します。購入フローに進む前に、これらの問題を修正してください。
   • サンドボックス環境をセットアップします。アカウント切り替えをテストする場合は、複数のサンドボックステスト ID を用意しておきます。
   • デバッグオーバーレイ（debugRevenueCatOverlay()／DebugRevenueCatBottomSheet）を案内し、オファリングのプレビューやテスト購入をすばやく行えるようにします。
3. 目的をリファレンスのユースケースに対応付け、以下の計画を作成します。

リファレンス実装（特に Flutter 向け）： RevenueCat は公式のPurchase Testerサンプルアプリを github.com/RevenueCat/purchases-flutter/tree/main/revenuecat_examples/purchase_tester で提供しています。これは、このスキルでテストするフローを実行できるアプリです。商品変更（product_change_testing_screen.dart）、ペイウォールとペイウォールのフッター、カスタマーセンター、仮想通貨、ウィンバックオファー、カスタムのペイウォール表示テスト専用の画面が用意されています。また、エンドツーエンドの統合テストも integration_test/app_test.dart にあります。Flutter ユーザーには、（a）正常動作が確認されたビルドを実行して、問題が自身のコードにあるのか、ストアまたは RevenueCat の設定にあるのかを切り分けること、（b）独自の integration_test ウィジェットテストを app_test.dart を参考に作成することを案内してください。Flutter 以外の SDK については、RevenueCat が各 SDK リポジトリで同等の Purchase Tester アプリを提供しています。

5つのテスト領域

references/use_cases.md から該当する行を抜き出します。対象範囲は次のとおりです。

1. サブスクリプションのライフサイクル — 購入、無料トライアル／初回特典（period_type = TRIAL／INTRO）、更新、アップグレード／ダウングレード（PRODUCT_CHANGE）、キャンセル、有効期限切れ、返金。必ず指摘するプラットフォーム上の注意点： iOS のサンドボックスでは返金できません。App Store ではユーザーが Apple サポートに案内され、CANCELLATION／CUSTOMER_SUPPORT イベントが届くまでに約24時間かかる場合があります。Google Play の返金はダッシュボードから行います。
2. 設定 — 匿名と識別済みの App User ID（デバッグログと CustomerInfo で確認）、オファリングの表示、ログイン／ログアウト。ここでの主なリスクは、アカウント間で意図しないデータの統合が起きることです。
3. 復元フロー — アカウント切り替え／移行のマトリックス。最も重要で、バグが起きやすい領域です。syncPurchases()、新しい ID への復元、3つの ID が関係する競合ケース（サブスクリプションを持たない ID への移行は成功する一方、すでにサブスクリプションを所有している ID への移行はエラーになる）、移行を無効にした場合の動作を扱います。全体を通じて確認するシグナルは、TRANSFER イベントが発生するか（または正しく発生しないか）です。
4. ペイウォール — 表示と購入、ローカライズ（デバイス／ストアアカウントの国 → 言語とローカライズされた価格）、新規ユーザーに対する初回特典の利用資格の表示。
5. RevenueCat Billing（ウェブ） — 購入、トライアルの自動移行、有効期限切れ。

成果物

• QA テスト計画 — アプリに該当するユースケースのチェックリスト（モバイルのみの場合はウェブ課金を省略し、トライアルがない場合はトライアルを省略）。各行は「操作 → 期待されるイベント／シグナル → 確認場所」の形式にします。主な成果物として、QA ドキュメントや課題管理ツールにコピー＆ペーストできる形式にしてください。
• 特定の失敗のデバッグ — リファレンスに基づいて原因を診断します。前提条件の問題（無効な製品 ID、ログがオフ、サンドボックスアカウントの誤り）なのか、シグナルに対する期待の誤り（移行が無効なのに TRANSFER を期待しているなど）なのか、プラットフォームの違い（iOS の返金はサンドボックスでテストできない）なのかを判断します。期待されるイベントとその確認場所を示し、実際に確認できている内容から原因をたどってください。
• 復元／移行の手順案内 — アカウント切り替えでユーザーが困っている場合は、個々の ID 設定と、各 ID で期待される TRANSFER またはエラーの結果を具体的に説明します。ドキュメントで最も詳しく扱われている領域です。
• サンドボックスの設定ガイド — 前提条件のセクションを、対象のプラットフォームと SDK に合わせて案内します。

推奨事項はすべて、references/use_cases.md で検証可能なシグナルと結び付けてください。同ファイル末尾のイベント早見表には、各イベントが何を証明するかが記載されています。