✅ [RUM-15484] bootstrap integration test infrastructure#91
Conversation
30273ad to
f1bccc2
Compare
f1bccc2 to
e17a135
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e17a1355c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
e17a135 to
0e864ef
Compare
- Add Playwright config generating dev/packaged projects - Add test:integration:* scripts to package.json - Add installation script to build all apps before tests - Add integrationFixture.ts handling dev/packaged app launch + intake server - Add integration scenario skeleton (view, renderer error, crash reporting) - Add GitLab CI job running in parallel with e2e - Exclude integration/apps from root lint and typecheck
abaeb22 to
ac79dc7
Compare
ac79dc7 to
0822d47
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0822d4709b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
since we do it manually for crash test, it would generate a useless extra instance
cdn34dd
left a comment
There was a problem hiding this comment.
Overall looks good, just a couple of minor tweaks.
The tests were written with `waitForEventCount('view', 2)` but only ever
received 1 bridge view event reliably. They appeared to pass on main
because the old `waitForEventCount` silently returned whatever events
were available on timeout instead of throwing — so the count=2 assertion
was effectively never enforced.
Our branch made `waitForEventCount` throw on timeout, correctly surfacing
the issue. Investigation showed:
- browser-rum sends view event 1 immediately during `datadogRum.init()`
- view event 2 (load-complete update) is deferred by a 3000ms throttle
(`THROTTLE_VIEW_UPDATE_PERIOD`, `leading: false`) and arrives after
`flushTransport()` has already run, so it never reaches the intake
within the test window
count=1 is the correct, honest expectation: it reliably verifies that
bridge events flow from renderer → IPC → main process → intake.
Motivation
The existing E2E tests use a minimal fixture app, which doesn't catch issues that only surface in specific customer toolchains (different bundlers, packagers, module formats, or dev vs packaged environments). This PR adds integration tests that validate the SDK against realistic Electron app setups.
Changes
forge-webpack,forge-vite,electron-vite, andelectron-builder-vite— each covering a different bundler/packager combination and SDK preload loading strategyintegrationFixture.ts) handling app launch in dev and packaged modes, with a local intake server capturing RUM eventstest:integration:init/test:integrationscripts and a dedicated CI jobyarn pack) to mirror the npm install experienceTest instructions
To test a specific app/mode:
Checklist