Skip to content
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

[Feature]: Jest should use the debugger statement on failure #15168

Closed
Lectem opened this issue Jul 8, 2024 · 10 comments
Closed

[Feature]: Jest should use the debugger statement on failure #15168

Lectem opened this issue Jul 8, 2024 · 10 comments

Comments

@Lectem
Copy link

Lectem commented Jul 8, 2024

🚀 Feature Proposal

By default, jest should use the debugger statement on assertion failure. This could also be behind a configuration parameter.

Motivation

This would make it way easier when using a debugger to break directly on failing assertions instead of having to put breakpoints manually, or break on all "Caught exceptions" which means you would break on your own exceptions too.

Example

No response

Pitch

Some test is failing and you want to debug it.
You run it through the debugger, but the process exits right after the exception failed.
You realize you now need to put, manually, a breakpoint after finding the line throwing the assert. Worse, if you happen to have some reusable function that wraps jest's expect call, you might break many times before finally finding the call that actually causes issues.
All of this could have been avoided if you let the test framework tell the debugger when to break !

Copy link

github-actions bot commented Aug 7, 2024

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Aug 7, 2024
@Lectem
Copy link
Author

Lectem commented Aug 7, 2024

Up

@SimenB
Copy link
Member

SimenB commented Aug 9, 2024

Huh, interesting feature request! I like it. Not sure where it would be hooked up, tho. In expect?

@Lectem
Copy link
Author

Lectem commented Aug 12, 2024

Ideally as close to the test code as possible or somewhere you can know what failed I guess.
I suppose where the check is actually done would be OK?
I'm not familiar enough with jest internals to know about that. In any case one could just go up the stack to find the faulty code!

Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Sep 11, 2024
@Lectem
Copy link
Author

Lectem commented Sep 11, 2024

Keep issue alive

@github-actions github-actions bot removed the Stale label Sep 11, 2024
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Oct 11, 2024
Copy link

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 10, 2024
Copy link

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants