Migrate e2e tests from cavy to react-native-cavynext, add web e2e support

[tvanlaerhoven]

Summary

Replaces the forked cavy/cavy-cli packages in the e2e app with react-native-cavynext / react-native-cavynext-cli (published on npm), modernises the specs, and adds web (react-native-web) e2e support.

Test framework migration

• cavy / cavy-cli (github forks) → react-native-cavynext / react-native-cavynext-cli ^0.1.0 from npm
• Specs use cavynext's Jest-style expect (the hand-rolled expect in utils/Actions.ts is removed)
• Platform-specific suites via spec.describeIf(...): presentation-mode tests skip on web (fullscreen needs a user gesture), rendering-target tests run on Android only; skips show up in the report
• Presentation-mode and rendering-target switching run on plain sources only: an IMA pre-roll added an ad-server dependency and ~10s of ad play-out per case without covering anything those specs assert

Player test layer (e2e/src/utils)

• The player under test is registered in cavynext's TestHookStore by TestableTHEOplayerView instead of a module-level global; specs obtain it with getTestPlayer(spec). It is unregistered synchronously on unmount, so a test can never grab the previous, about-to-be-destroyed player
• getTestPlayer gives a freshly created player a settle time before a spec sets a source. The runner re-mounts the view before every test and cavynext awaits that re-mount, so without it a source lands on a player that is milliseconds old while its predecessor is still being released natively — which made iOS/tvOS fail with MEDIA_AVPLAYER_ERROR (5003) on the mp4 source. Forked cavy hid this behind the 1s poll interval of its player lookup:

   const player = await spec.findComponent(PLAYER_HOOK_ID);
  +await new Promise((resolve) => setTimeout(resolve, PLAYER_SETTLE_TIME));
   return player;

• waitForPlayerEvents rewritten: listeners and the timeout are always cleaned up, rejections are real Errors carrying a player-state snapshot, and unrelated events no longer break in-order matching
• New seekTo(player, time) helper
• The test app is no longer wrapped in <StrictMode>: its double-invoked mounts created and destroyed a second native player per test, and made React DevTools log every line twice

Web e2e support

• npm run test:e2e:web runs the suite in Chrome via cavynext run-web + webpack dev server (e2e/web/), launched with a dedicated user-data-dir and throttling disabled so background timers/playback keep running
• mutedAutoplay: 'all' on web (browser autoplay policy) and transmux workers copied from the repo root's theoplayer package so SDK and worker versions match

Library

• THEOplayerAdapter clears its cached paused state on play, not only on playing, so player.paused no longer stays true for the whole play → playing gap

CI

• pr_ios.yml / pr_android.yml updated for the cavynext CLI and cavynext_results.md
• The tvOS pods target gets its Nielsen framework name rewritten to NielsenTVAppApi again, without which the tvOS app fails to link (ld: framework 'NielsenAppApi' not found)

Test results

Platform	Result
Web	✅ 28 examples, 0 failures, 12 skipped
Android (emulator, release)	✅ 28 examples, 0 failures
iOS (simulator)	✅
tvOS (simulator)	✅

Notes

• Rebased on develop (RN 0.86.2)
• The e2e lockfile is based on develop's with cavy removed and cavynext added incrementally: a from-scratch npm install fails on the $react-native override reference (pre-existing on develop, worth a separate fix)
• e2e/ios/Podfile.lock was regenerated without e2e/scripts/patch_ios_podspec.sh having run first, so it lacks the IMA/Chromecast/THEOads/Millicast integrations. CI patches the podspec and runs pod update, so only a plain local pod install is affected

Link to Devin session: https://dolby.devinenterprise.com/sessions/69e1051f15d743c690a56c0a7bd9018b
Requested by: @tvanlaerhoven

---

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 Shorter mp4 test asset may end before later assertions run

The mp4 fixture switched to demos/me.mp4. Several specs assume playback is still ongoing several seconds in: PresentationMode.spec sleeps 500ms after each mode switch and asserts player.paused is falsy, and Basic.spec seeks to 5s. If the new clip is short, ended (which pauses the player) could make those assertions flaky on slower runners. Worth confirming the asset's duration is comfortably longer than the ad pre-roll + seek + mode-switch sequence.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Checked: demos/me.mp4 is 10.03s (629 KB, 640x360 h264/aac, ffprobe-confirmed), and no spec needs anywhere near that much play-out. The presentation-mode case is two mode switches with one 500ms sleep (~1-2s after playing), the Android rendering-target case is 2x 500ms plus a timeupdate, and Basic.spec now seeks to 5s instead of 10s — that seek change is part of this commit precisely because 10s was the clip's duration. The Ads spec uses ads.json (VAST tag), not this fixture, so the pre-roll doesn't eat into it.

The switch is deliberate: the 47 MB elephants-dream.mp4 was the direct cause of the iOS 5003 failures. Each test cancelled its 46 MB range read mid-body (finished with error [-999]), Fastly closed those sockets, and the next player picked one out of CFNetwork's pool (connection=18, reused=1) → error code: 303 [4:-2205] → CFByteFlume: Read failed during non-interactive download. Give up immediately. → -12935 → FailedToBecomeReadyForPlayback. A fixture that completes in a single request leaves nothing in flight to abort.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 Dev-server script exits non-zero when terminated by the runner

With set -euo pipefail, wait "${WEBPACK_PID}" returns non-zero when the script is signalled/terminated by the cavynext CLI at the end of the run, so the build command exits with a failure status (e.g. 143). Whether that is surfaced as a failed test run depends on how cavynext run-web treats the exit code of --buildCmd; if it does, CI would report a spurious failure after a successful run.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Hedge resolves empirically: the e2e (web) job is green on every run of this branch, and it always ends this way — cavynext terminates the --buildCmd process itself after reporting results, so the 143 goes to a process whose exit code the CLI doesn't propagate. The job's own exit code comes from cavynext run-web, which is what pr_web.yml waits on.