Expecting existing DebugElement toBeFalsy creates circular reference in Jasmine

I’m submitting a … (check one with “x”)

[X ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior When you test to see if a DebugElement that exists but shouldn’t is falsey, Jasmine churns on Plunker but eventually returns sort of. On Angular-CLI on WebStorm, it will keep cycling with a circular reference as it tries to print out the DebugElement to compare it to falsey. It’s actually hard to figure out that’s what happens because it just scrolls and scrolls and the only chance you have to Ctrl-C is when karma is restarting after it gets fed up.

Expected behavior String representation of debug element should be able to be written to console in a reasonable amount of time.

Minimal reproduction of the problem with instructions https://plnkr.co/edit/6a7iKt80GAVdhW9MRrPx

What is the motivation / use case for changing the behavior? People who embrace test first development will write the minimal template without the *ng directive that hides it under testing circumstances.

Please tell us about your environment: Windows 10, Webstorm 2016.2.4 Angular-CLI 1.0.0-beta.20-4

• Angular version: 2.0.X Locally I have 2.1.0, but I’m assuming that since I forked your plunk for the steps to reproduce, it’s still an issue.

• Browser: Edge, but I imagine it’s all

• Language: [all | TypeScript X.X | ES6/7 | ES5] TS

• Node (for AoT issues): node --version =

[psxvoid]

It’s still an issue in angular 4.4.4

[dwilches]

I hit this bug today in Angular 4.2.4. While this issue gets addressed, I posted a workaround here: https://stackoverflow.com/questions/44301315/karma-error-no-captured-browser-open-http-localhost9876/48606192