-
Notifications
You must be signed in to change notification settings - Fork 3.4k
fix: normalize test body invocationDetails from stack traces
#32699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
… invocationDetails
cypress
|
||||||||||||||||||||||||||||||||||||||||
| Project |
cypress
|
| Branch Review |
astone123/fix-itgrep-trace
|
| Run status |
|
| Run duration | 19m 13s |
| Commit |
|
| Committer | astone123 |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
|
|
0
|
|
|
14
|
|
|
1108
|
|
|
4
|
|
|
26602
|
| View all changes introduced in this branch ↗︎ | |
Warning
Partial Report: The results for the Application Quality reports may be incomplete.
UI Coverage
45.48%
|
|
|---|---|
|
|
188
|
|
|
161
|
Accessibility
97.98%
|
|
|---|---|
|
|
4 critical
8 serious
2 moderate
2 minor
|
|
|
101
|
|
@mschile @mabela416 |
mabela416
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested it locally and it works
| } | ||
| } | ||
|
|
||
| // if the stack includes the 'itGrep' function, remove any lines that include it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely good to reference what itGrep is and where it is coming from (same with above) https://github.com/cypress-io/cypress/blob/develop/npm/grep/src/register.ts#L77. people who aren't familiar with @cypress/grep will struggle to understand what this means.
The other concern I have is that there could be something legitimate in the stack that has itGrep in it that we want to capture but are omitting it here. Or is this only considered when trying to calculate the row/column in the spec file where the error occurred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment there. I'm pretty sure this function is specifically used to identify where the test was executed from, so this shouldn't affect anything else. If it does, it'll be limited to use of the grep plugin
|
@mschile I updated this so that it works for tests with .only as well as tests that are nested in suite definitions |
itGrep lines from stack trace when determining invocationDetailsinvocationDetails from stack traces
Co-authored-by: Matt Schile <[email protected]>
Co-authored-by: Matt Schile <[email protected]>
Co-authored-by: Matt Schile <[email protected]>
Co-authored-by: Matt Schile <[email protected]>
Co-authored-by: Matt Schile <[email protected]>
| line.trim().startsWith('at eval') || | ||
| line.trim().startsWith('at Suite.eval') | ||
| ) | ||
| }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Flawed Stack Trimming Breaks Test Debugging
The Chromium stack trimming logic uses startsWith('at eval') and startsWith('at Suite.eval'), which incorrectly matches function names like evalScripts, evaluate, or Suite.evalSomething. This causes the stack to be trimmed at the wrong location, breaking invocation details for tests when such function names appear in the stack trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can probably add a space to at eval and at Suit.eval
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call, added a space to the end of those
| // There are cases where there are other lines in the stack trace before the invocation (eg. `context.it.only`, `createRunnable`, etc) | ||
| // The actual test invocation line starts with either 'at eval' or 'at Suite.eval', | ||
| // so remove all lines until we reach the test invocation line |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // There are cases where there are other lines in the stack trace before the invocation (eg. `context.it.only`, `createRunnable`, etc) | |
| // The actual test invocation line starts with either 'at eval' or 'at Suite.eval', | |
| // so remove all lines until we reach the test invocation line | |
| // The actual test invocation line starts with either 'at eval' or 'at Suite.eval', | |
| // so remove all lines until we reach the test invocation line |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
| }) | ||
|
|
||
| // if we removed all the lines then something went wrong. return the original stack instead | ||
| if (modifiedStack.trim() === 'Error') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems brittle, I think in the stackWithLinesRemoved callback above, you can create a copy of the lines and then do your processing on that copy. Before returning lines, you can check if all of the lines were removed and if they were, you can return the original lines, otherwise return the copy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated this to create a copy of the lines and check to make sure there are lines in the copy before returning it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this spec is correct (possibly AI generated nonsense?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this spec in favor of packages/driver/cypress/e2e/cypress/stack_utils-invocationDetails.cy.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also have an existing stack_utils.cy.js file that we can add to for any getInvocationDetails tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ended up making a separate spec for these instead of adding them to stack_utils.cy.js
| // if the hook is the test, and it's an e2e test,, we will try to remove the lines that are not the actual invocation of the test | ||
| if (type === 'test' && specWindow.Cypress.testingType !== 'component') { | ||
| stack = stackTrimmedToTestInvocation(stack, specWindow) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Prevent errors from missing Cypress object.
Accessing specWindow.Cypress.testingType without checking if specWindow.Cypress exists will throw an error when users quickly reload tests, since specWindow.Cypress can be null or undefined in those cases. The check should be inside the existing if (specWindow.Cypress) block or include its own null check.
This PR closes https://github.com/cypress-io/cypress-services/issues/11991
Additional details
There are a few cases where we don't correctly derive the test body invocation details from the stack trace. This PR fixes those scenarios by looking for
at evalorat Suite.evalin Chrome stack traces, and lines with anonymous functions in Firefox stack traces. This will allow Cypress Studio and "Open in IDE" features to work in more cases than they did before.One of these situations is when
ithas been re-written asitGrepwhich happens in the@cypress/grepand@bahmutov/cy-grepplugins. This allows us to determine the correct invocation details for the test.Steps to test
I tested this with the
@bahmutov/cy-greppackage. Install the package and register it in your support file in accordance with the documentation. Open Cypress Studio by clicking the "edit in studio" button next to a test. Verify that the test content is loaded correctly and you can edit and save the test as expected.How has the user experience changed?
Users of
@bahmutov/cy-greppackage can now use Cypress studio as intendedPR Tasks
cypress-documentation?type definitions?Note
Normalizes test-body invocationDetails by trimming stacks (Chrome/Firefox, including wrapped it), updates reporter to send correct IDE targets, adds comprehensive e2e/unit tests, and updates changelog.
stack_utils: addstackTrimmedToTestInvocationand enhancegetInvocationDetails(specWindow, root, 'test')to trim to actual test invocation (Chromium:at eval/at Suite.eval; Firefox: anonymous frame). ExportInvocationDetails.mocha.ts: pass'test'when settingtest.invocationDetails.it.stack_utils-invocationDetails.cy.tsvalidating Chrome/Firefox and wrappeditline/column/stack.wrapped-it.cy.jsfixture.Written by Cursor Bugbot for commit 50418a8. This will update automatically on new commits. Configure here.