RevenueCat Testing

Help a developer systematically verify their RevenueCat integration works before shipping — turning "I added RevenueCat, does it actually work?" into a concrete, checkable QA plan. The full use-case matrix, methods, platform differences, and the verifiable signal for each case live in references/use_cases.md. Read it for exact event names and preconditions; this file is the operating guide.

The organizing principle: every RevenueCat behavior has a verifiable signal — a specific dashboard event (INITIAL_PURCHASE, TRANSFER, EXPIRATION, PRODUCT_CHANGE, CANCELLATION), a period_type value, or a CustomerInfo/debug-log state. A test isn't "did the app not crash"; it's "did the expected event appear in the customer's history with the right fields." Always tie a test to its signal, or it isn't really testing anything.

How to use this skill

1. Get the setup facts: platform(s) (iOS / Android / cross-platform / web billing), SDK (native, RN, Flutter, etc.), whether they've enabled debug logs and sandbox accounts yet, and what specifically they're trying to verify or why they think something is broken.
2. Establish prerequisites first — most "purchases don't work" reports are config problems visible before any purchase:
   • Debug logs on before configure() (iOS Purchases.logLevel = .debug; Android setLogLevel(LogLevel.DEBUG)), and check for "Invalid Product Identifiers" and error-level logs. Fix those before touching purchase flows.
   • Sandbox environment set up; multiple sandbox test IDs ready if any account-switching is in scope.
   • Point them at the debug overlay (debugRevenueCatOverlay() / DebugRevenueCatBottomSheet) to preview offerings and run test purchases quickly.
3. Map their goal to use cases from the reference and produce the plan (below).

Reference implementation (especially for Flutter): RevenueCat ships an official Purchase Tester sample app at github.com/RevenueCat/purchases-flutter/tree/main/revenuecat_examples/purchase_tester. It's a runnable app exercising the flows this skill tests — dedicated screens for product change (product_change_testing_screen.dart), paywalls and paywall-footer, customer center, virtual currency, winback offers, and custom paywall-impression testing — plus an end-to-end integration test at integration_test/app_test.dart. Point Flutter users there to (a) run a known-good build to isolate whether a bug is in their code vs. their store/RevenueCat config, and (b) model their own integration_test widget tests on app_test.dart. For non-Flutter SDKs, RevenueCat has equivalent Purchase Tester apps in each SDK repo.

The five testing domains