Debugging Karma Tests with angular-cli - Breakpoints are omitted
Hi,
1) I created a new angular-cli projekt using "ng new karmaTest".
2) Under Run/Debug-Configurations I created a new Karma configuration:
Note I did not add a compilation task to be run before launch, because as I understand it, angular-cli will comile typescript files into memory when I run this debug configuration.
Here is the karma.conf.js (that was automatically created using "ng new". I made minor changes like adding 'sourceMap' true because of the advice in an another forum post, but it did not help.):
3) I added breakpoints in the "app.component.spec.ts" and "app.component.ts".
4) I started the karma configuration using the Debug button.
5) In the browser I can see, the 3 karma tests passed. However my breakpoints are not invoked. Any idea as to why?
I am using the newest release candidate Webstorm 2017.2 (but the problem was the same in 2017.12).
(In 2017.2 the new webpack package resolution is supported.)
Please sign in to leave a comment.
should be resolved in Angular CLI 1.3.0-beta.1
See here:
https://github.com/angular/angular-cli/pull/6862#issuecomment-315720213
If let me add something I would appreciate any information concerning running one karma test. I experience the same problem as @De Schubert Richard described, but also whenever I try to start a single tests all test are run again and all breakpoints are ignored. As I see the breakpoint ignore is angular-cli dependent, but what about running a single test? Thanks in advance for a response.
Can someone at Jetbrains please comment about when WebStorm will support this feature? We are customers as well, and we need it. Thanks.
Debugging karma tests works fine for me; if you have problems using this feature, please provide a project that shows it up
@Elena Thank you for replying, though where in this page was anyone only asking about debugging Karma tests? If there is a way of debugging ng test runs using Angular CLI to run Karma specs using WebStorm where it stops on a breakpoint (since this page was always specifically about that use case), please give us the link to the WebStorm documentation page where it shows the procedure for getting that working, or type the procedure in here for us to try. Thank you.
There are no special procedures - debugging karma tests in angular-cli projects works out of the box: you can click the gutter icon next to the test in the editor and choose Debug<test name>:
Just make sure to enable sourcemaps for test target in your angular.json - they are disabled by default:
Its not working after upgrade to angular 6 and angular cli 6.1.2
Please make sure to enable sourcemaps - see above
Even with sourcemaps enabled, this doies not work with PHPStorm 2019.1 and Angular 7
works for me even if sourcemaps are not enabled explicitly (PhpStorm passes --source-map option when debugging karma in Angular apps to overcome the problem). Can you recreate the issue in a new project?
Hi Elena,
thanks for taking time to look at this.
I retested it and it works now. It seemed to be a hiccup whith an already running Karma instance. I guess the Problem was somehow related with the following workflow in an Angular 7 Project:
I'll watch out if this happens again and if can provide a reproducable example. Unfortunately I cannot do this with the Project where this happened, because of IP restrictions.
I see, thanks for update:)
Please keep me posted
Now this is Broken again after upgrading from Angular 7 to 8. No breakpoints are recognized, even when sourceMaps are explicitly turned on.
I found the issue and I hope it helps somebody else who may run into it:
When your karma.conf.js defines browsers with one of the following ("ChromeHeadless", "ChromeHeadless", or "ChromiumHeadless"), PHPStorm (actually the bundled karma-intellij-debug.js) will ALWAYS force a fixed debug port.
When you then configure a Test-Run with the --browsers option to another browser (i.e. Firefox) the debugger will not be able to cummunicate.
Solution: Don't put any of the browsers above in your karma.conf.js or make it conditional, so that intellij's scripts dont fall for this case.