Testing Real OpenRTC Behavior

How to test native, Tauri, and browser OpenRTC clients through service-backed production flows.

Testing Real OpenRTC Behavior

OpenRTC product tests should prove the same flow users hit: managed auth, service-backed device discovery, presence, auto-connect, Rust-owned admission, peer-session settling, application traffic in both directions across the settled route, and optional transport upgrade state.

For OpenRTC platform contributors, the repository's default emulator suite includes the real native acceptance path:

pnpm --dir openrtc/packages/openrtc run test:emulator

For a focused run with emulators already up:

pnpm --dir openrtc/packages/openrtc run test:acceptance:native:running

This focused command expects the coordination gateway plus Functions, Firestore, and API Hosting emulators to be running. The retired OpenRTC Auth and RTDB emulators are not part of the current test lane.

The shared helper lives at packages/openrtc/tests/harness/realOpenRtcAcceptance.ts. Downstream apps can reuse it by adapting their app host to the same peer shape: authenticate, initialize, publish presence, list devices with status, start auto-connect, wait for settled peers, send a heartbeat in both directions when the host and guest expose responders, and request upgrades when enabled.

Use the avenue acceptance matrix in docs/testing/avenue-acceptance-matrix.md when a change touches discovery, rooms, tickets, presence, or connection lifecycle. Each test should name the avenue it proves: user-device, space, room, or ticket/share grant.

Keep app-traffic assertions and upgrade-state assertions distinct. Native WebRTC may connect as a parallel transport before it owns generic app-stream delivery, so a connected data channel alone is not proof that a browser-to-native app payload reached the native application responder.

Do not replace this lane with fake rosters or assumed connection state. Those belong in contract/unit tests; release confidence comes from the service-backed acceptance path.

Application developers using the published SDK do not need the OpenRTC source repository or platform emulators. Test the published package against your own test developer-app identity on the managed public service, and keep your application's auth, database, billing, and deployment tests in the application repository.