WebStorm refusing to stop at many breakpoints while debugging Jest tests in IDE
Today, I cannot convince WebStorm to stop at many of my breakpoints when I'm debugging Jest tests.
Current WebStorm version: 2020.2.1. What other versions you want?
My workflow is, I have a test file open, and I right-click in the gutter and select "Debug 'the test name'" from the menu:
I have breakpoints in the test file, and I also have breakpoints set in my application source code. WebStorm will stop at the breakpoints that are in the test file itself, and a *few* of the breakpoints in source files, but not all. The breakpoints have checkmarks.
I will attach a video of this happening - Upload id: 2020_09_09_YVdibHQvMVpuC8ra (file: webstorm_not_stopping.mp4)
I have stopped and restarted WebStorm, rebooted, and upgraded Webstorm to 2020.2.1 (from 2020.2.0) today, and nothing has affected the situation.
Thanks,
Eric
Please sign in to leave a comment.
please check your
jest.config.js- what does it look like? Do you havecollectCoverageenabled in it?If the source file is instrumented for coverage, the generated code can't be correctly mapped to source; it's a well known limitation
We don't have collectCoverage enabled, and I'm not running "with Coverage" (I'm debugging). We did have collectCoverageFrom defined for jest in package.json, but taking that out didn't help matters.
This is crippling my productivity. No ideas?
Could you share a project the issue can be repeated with?
Can't really share our web application development project, unfortunately, and we don't really have the resources to invest in trying to develop a standalone project that reproduces the problem. My colleagues are seeing the same behavior. I'd be happy to record videos or have screen-sharing sessions if that would help. I'm happy to answer any questions you might have about how our project is set up.
Here is another clue that might help you? Suppose you have a function with several breakpoints in it that WebStorm is not hitting. If you can find a way to step into that function, and hit Go, those breakpoints are still not hit. However, if, after you step into the function, you delete and recreate the breakpoints in the function, they will get hit if you hit Go.
My colleague suspects this issue has something to do with "jest utilizing babel", in case that helps.
This can indeed be related to babel (namely, to sourcemaps it generates) - if they are not accurate enough, certain lines of code would not be mapped correctly and not resolved while debugging. But I can't tell for sure unless I have a project to play with
After one year I'm still facing this problem, im running Jest with NestJS and sometimes the breakpoint works, sometimes it doesnt. Almost going back to VSCode, work without debug in Jest is terrible.
Hmm... do you mean that debugging work in VSCode? this can be a bug in Webstorm then, the project the issue can be reproduced with would be helpful
Closing in on two years since reporting this problem, and there has been no progress. This will be the reason my team stops using WebStorm.
Let me describe what happens more completely, since I've experienced the problem so many times I have it memorized.
1. I start debugging my node.js application in WebStorm. It connects to the debugger successfully and hits breakpoints just fine. This might happen 3, 4 or 5 times.
2. Then, at some point, when I start debugging my node.js application, the debugger connects successfully, but when I get to a point where a breakpoint should be hit, the breakpoint does not *appear* to have been hit, but the application I am debugging does not progress either. It is as though the breakpoint has actually been hit internally, but the WebStorm UI does not realize it.
3. If, at that point, I stop the debugger and try to start debugging again, the debugger will fail to connect. No matter how many times I stop debugging and start again, the debugger will "fail to connect after timeout" until I kill WebStorm and start it up again. Then, I go back to step 1 above, rinse and repeat.
I can't send you my project and all of its proprietary source code. You're going to have to develop a reproducible case, or send a developer to where I work and you can see it happen.
Sometimes, like just now, the number of times it succeeds in step 1 after restarting WebStorm is 0.
I will say this: In a half-day of anecdotal attempting to debug my application, the debugger seems to go out to lunch a lot less if I am running a single instance of my application, rather than running it in cluster mode, which these days launches like 12-16 instances. I'm not saying it never exhibits the problem, because a second node.js application that *can't* run in cluster mode does exhibit this problem sometimes, even several times today.