If you've ever watched a QA engineer press "call" on one laptop, walk across the room, and press "answer" on a phone before the ringing stops, you already know the setup. Two-browser sync is the single hardest part of WebRTC video call testing.
The whole flow looks simple on a whiteboard. Alice presses call, Bob's screen lights up with an incoming banner, Bob answers, video panes appear on both sides. All of it has to be automated without breaking the timing. One script, two contexts, and enough patience to let ICE finish. That's the shape of it.
I wrote this after replacing a two-person manual regression pass for a video call app. The team ran that check every merge to main, and every time it involved two people, two devices, and a Slack thread that started with "wait, ready?" Now one Playwright script does it in about 40 seconds on CI, and it fails loudly at the merge when signaling regresses.
Why two browsers and not one page
The instinct on a first pass is to open one page and simulate both sides. That works for signaling unit tests. It fails for anything that involves peer connection state, because the local peer and the remote peer end up sharing the same JS runtime and the same fake camera, and every failure mode that matters in production stays invisible: race between offer and answer, ICE candidate ordering, DTLS handshake stall.
