Show jest tests which ran in the recording as console messages

[bhackett1024]

WIP for https://github.com/RecordReplay/devtools/issues/5439

This identifies the jest tests in a recording and adds console messages for each of them, which can be clicked on to jump to the start of the test. This still needs to deal with test failures.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/recordreplay/devtools/7YM6NuK4pig8qBuv4h8CTkuvDPrJ
✅ Preview: https://devtools-git-jest-tests-recordreplay.vercel.app

[qa-wolf]

✅ QA Wolf - PR deployment

Sitka here: 29 tests ran, see details here.

✅ 29 pass

✅ Filter console by errors from user role

✅ Filter console by event type (search) on user role

✅ Filter console by logs on user role

✅ Filter console by mouse click using user role

✅ Filter console by warnings

✅ Hide node modules with user role

✅ Log in and out

✅ Make recording private and public

✅ Open console from search anything component with user role

✅ Open full text search from search anything component and search text on user role

✅ Open print statements from search for anything component

✅ Open search for file from search anything component and search

✅ Open search for function from search anything component and search

✅ Open viewer from search anything component with user role

✅ Play and pause replay

✅ Share recording with link and email

✅ Share replay via invite link: members of QAWolf :: Facebook

✅ Share replay via invite link: members of Test team

✅ Share replay via invite link: only people with access

✅ Show privacy information from search anything component using user role

✅ Show timestamps with user role

✅ User role can: expand demo file, open index and demo-script.js

✅ User role unable to: access billing, view api keys, delete team, edit team name

✅ User role unable to: open replay menu, bulk edit replays

✅ Using console evaluations is prohibited on user role

✅ View and click events

✅ View and filter outline with user role

✅ View and search library

✅ View footer links: about

[bhackett1024]

This PR adds new functionality where on each recording we look for the jest test runner source "jest-circus/build/utils.js", and if found kick off some analyses to look for places where jest tests ran and failed. Tests and failure messages are added to the console. For failures, we're able to extract the full error message from the expect() module and include it in the console error, but only the first line of the message is shown and I'm not sure how to fix that. This and plenty of other refinements are definitely possible here, but this should be a good starting point.

Replay of the new functionality in action:

https://app.replay.io/recording/jest-tests--b5df685f-74c4-4f88-85f1-006944ca0193

[SimenB]

note that we might start bundling (jestjs/jest#12348) at which point at least the filename will break and possibly the function name (depending on sourcemaps).

Not sure how to handle that. It would be better to have a real hook for this (e.g. handleTestEvent in the env?), but that might not be feasible - I have no idea how this project works.

[bhackett1024]

Definitely, the pattern matching on file names and code patterns in this PR is not robust at all, and longer term it would be great to have a way of identifying places where tests started and failed that doesn't rely on detecting these patterns. We have a mechanism to add annotations to a recording which could be used to find these points. It isn't currently exposed in node, but if it was we could have something like:

if (process.addRecordReplayAnnotations) {
  process.addRecordReplayAnnotation("JestTestStart", { ...info about test... });
}

I don't know if it would be possible to use handleTestEvent for this --- we would need these annotations to be as close as possible to where the test starts running, so we can find the entry point to the test function which was passed in. Right now we pattern match to detect the calls to the test function, and then step in to each of those calls to find the point to jump to when someone clicks on that test.

[SimenB]

We have --testLocationInResults. Would that be enough? I would assume that info is also included in a handleTestEvent call, but I haven't verified. In that case you can at the very least point to where the test function is

[bhackett1024]

I think that would be enough. If the test event callback is notified about every test, and has the name of that test, the file/line/column of the test callback, and whether the test passed, that should be enough information to reconstruct everything we're getting from the pattern matching we're doing. The test callback would call process.addRecordReplayAnnotation with this information, and then the devtools can read that from the recording and use it to figure out where the tests ran.

[SimenB]

Yeah, its called when test is declared, execution starts, execution enda etc. I'm not 100% sure the location info is present for all cases, but if not we can probably fix that