Debugging ng test doesn't work

[weinand]

From @jrieken on June 27, 2017 8:43

testing #29476

The last step which is about debugging test doesn't work for me. Breakpoints appear as empty circles not discs.

Copied from original issue: microsoft/vscode#29539

[weinand]

From @chrmarti on June 27, 2017 20:45

Same here on Windows. ng test spawns a Chrome window which is not mentioned in the recipe and the launch config the spawns another window that doesn't trigger the breakpoints.

[weinand]

The test setup (ng test) seems to have changed in a bigger way: they are now based on karma (which I think they weren't before).

/cc @roblourens @tonysneed

[roblourens]

Was looking at this with @Lixire, and I couldn't even get sourcemaps loaded in chrome devtools.

[auchenberg]

Maybe related, http://blog.mlewandowski.com/Debugging-Karma-tests-with-VSCode.html?

[tonysneed]

@weinand I noticed recently that the source maps are an issue again -- this time with ng test.

[weinand]

@tonysneed I don't think it's just a source map issue. ng test now spawns a Chrome window which is not mentioned in the recipe. So the whole approach to these tests has changed.

[tonysneed]

@weinand I don't think the approach has changed in a way that can't be documented in the recipe. ng test still uses Karma like before, and the window that pops up has a debug button on it, which brings up the same url as specified in the test confit in launch.json.

So if the source map issue is resolved, we should be back on track with debugging tests with the chrome debugger extension for vs code. Can we get some input from someone on the A-CLI and/or the debugger extension teams?

[roblourens]

I can look into it later but I don't have time this week.

[auchenberg]

Running .scripts with a generated angular-cli 1.1.3 app gives me this

› VM45
› VM47
› VM49
› VM53
› VM55
› VM57
› VM59
› VM61
› VM63
› http://localhost:9876/_karma_webpack_/inline.bundle.js
› http://localhost:9876/_karma_webpack_/main.bundle.js
› http://localhost:9876/_karma_webpack_/polyfills.bundle.js
› http://localhost:9876/_karma_webpack_/vendor.bundle.js
› http://localhost:9876/base/node_modules/jasmine-core/lib/jasmine-core/jasmine.js (/Users/auchenberg/development/angular-demo/node_modules/jasmine-core/lib/jasmine-core/jasmine.js)
› http://localhost:9876/base/node_modules/karma-jasmine-html-reporter/src/lib/adapter.js (/Users/auchenberg/development/angular-demo/node_modules/karma-jasmine-html-reporter/src/lib/adapter.js)
› http://localhost:9876/base/node_modules/karma-jasmine-html-reporter/src/lib/html.jasmine.reporter.js (/Users/auchenberg/development/angular-demo/node_modules/karma-jasmine-html-reporter/src/lib/html.jasmine.reporter.js)
› http://localhost:9876/base/node_modules/karma-jasmine-html-reporter/src/lib/html.jasmine.reporter.js (/Users/auchenberg/development/angular-demo/node_modules/karma-jasmine-html-reporter/src/lib/html.jasmine.reporter.js)
› http://localhost:9876/base/node_modules/karma-jasmine/lib/adapter.js (/Users/auchenberg/development/angular-demo/node_modules/karma-jasmine/lib/adapter.js)
› http://localhost:9876/base/node_modules/karma-jasmine/lib/boot.js (/Users/auchenberg/development/angular-demo/node_modules/karma-jasmine/lib/boot.js)
› http://localhost:9876/context.js
› http://localhost:9876/debug.html
› http://localhost:9876/debug.js
› ng:///DynamicTestModule/AppComponent.ngfactory.js
    - ng:///DynamicTestModule/AppComponent.ngfactory.js (/Users/auchenberg/development/angular-demo/DynamicTestModule/ng:/DynamicTestModule/AppComponent.ngfactory.js)
    - ng:///DynamicTestModule/AppComponent.html (/Users/auchenberg/development/angular-demo/DynamicTestModule/ng:/DynamicTestModule/AppComponent.html)
› ng:///DynamicTestModule/AppComponent_Host.ngfactory.js
    - ng:///DynamicTestModule/AppComponent_Host.ngfactory.js (/Users/auchenberg/development/angular-demo/DynamicTestModule/ng:/DynamicTestModule/AppComponent_Host.ngfactory.js)
    - ng:///DynamicTestModule/AppComponent_Host.html (/Users/auchenberg/development/angular-demo/DynamicTestModule/ng:/DynamicTestModule/AppComponent_Host.html)
› ng:///DynamicTestModule/module.ngfactory.js
    - ng:///DynamicTestModule/module.ngfactory.js (/Users/auchenberg/development/angular-demo/DynamicTestModule/ng:/DynamicTestModule/module.ngfactory.js)

Looks like there's some magic bundeling going on now in ng:///DynamicTestModule/AppComponent.ngfactory.js, as the file names are vastly different then source.

[auchenberg]

Downgrading to angular-cli 1.1.1 resolves the issue. Seems to validate this reported issue in angular-cli. angular/angular-cli#6824

[roblourens]

That issue sounds very relevant :D

[weinand]

@auchenberg thanks for investigating this and finding angular/angular-cli#6824.
I will update the recipe to make users aware of that problem for angular-cli versions > 1.1.1.
We will try to fix this in July.

[daBishMan]

first off thank you so much for your work, and your time.

Can you please add steps to debug e2e tests, using protractor and the CLI

[tonysneed]

@weinand I'm working on PR #11 for the recipe for setting the exact version of Angular CLI to 1.1.1.

[weinand]

@tonysneed thanks a lot

[daBishMan]

@tonysneed @weinand just for learning purpose, whey running npm start vs. ng start ? if you have the same version of the CLI locally and globally it should be OK to go with ng start ?

[tonysneed]

@daBishMan So the issue arises when you update the global CLI package. If you run ng serve then you are using the global package, which would then be a greater version that the local package. If there is an issue with the newer version of the global package, such as broken source maps, then you may not be able to debug.

So it's much better to use npm start because you are guaranteed to use the local version which is set exactly (no caret or tilde) in package.json.

Also you can pass args to the npm command. For example to open the browser:

npm start -- -o

[daBishMan]

@tonysneed thank you :)

[tonysneed]

@weinand @daBishMan Happy to help! 😄

[daBishMan]

@tonysneed thank you so much for your help with this.

When I try to debug e2e tests I get the error below. Yes, the breakpoint gets hit in VS Code, but the test fails. Anyone else experiencing this?

You can check it out via this repo https://github.com/daBishMan/biz-app

1. biz-app App should display welcome message

• Failed: Error while waiting for Protractor to sync with the page: "window.angular is undefined. This could be either because this is a non-angular page or because your test involves client-side navigation, which can interfere with Protractor's bootstrapping. See http://git.io/v4gXM for details"
  Executed 1 of 1 spec (1 FAILED) in 9 secs.

[auchenberg]

@daBishMan I just clone your repo and ran Launch ng e2e from VS Code 1.14.1 and things work as expected after I first ran ng e2e from the Terminal (installed webdriver dependencies)

@angular/cli: 1.2.3
node: 7.9.0
os: darwin x64
@angular/animations: 4.3.1
@angular/common: 4.3.1
@angular/compiler: 4.3.1
@angular/core: 4.3.1
@angular/forms: 4.3.1
@angular/http: 4.3.1
@angular/platform-browser: 4.3.1
@angular/platform-browser-dynamic: 4.3.1
@angular/router: 4.3.1
@angular/cli: 1.2.3
@angular/compiler-cli: 4.3.1
@angular/language-service: 4.3.1

[daBishMan]

@auchenberg thanks again very much for your help yes, it does work now; really appreciate your time :)

[Looted]

I have a related issue so I'll just ask here instead of creating another issue. The debugging works for me in such way, that when I'm stepping forward, nothing happens in the browser. Only after I step out of the it blocks, the commands actually run in the browser. Is this the desired behavior? When running e2e tests in Ruby I could step forward and see what the browser is actually doing each step (so I could inspect the DOM state etc.)