revenuecat-testing

# 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 p...