Test development cycle is slow unless sourcemaps are turned off

[wardbell]

The iterating unit test development is painfully slow (and appears to grow slower during a session) when running ng test.

The console shows re-build 92% complete and then hangs for up to a minute (it seems anyway) before finally reporting test progress and refreshing the karma browser.

The test progress reporter ticks along at a slow pace.

However, ng test --sourcemap=false (turning off sourcemaps) results in crisp iterations, with rebuild times in the sub-second range.

I'm describing my experience on a small app (the new Angular DocViewer) with fewer than 100 tests so far.

Bug Report or Feature Request (mark with an x)

• bug report -> please search issues before submitting
• feature request

Versions.

4.0.0-rc.2,
OS/X, node 6.9.5, npm 4.1.2

Repro steps.

1. Open a CLI project with tests.
2. Develop tests in a single spec file with ng test, changing frequently.
3. Do the same again with ng test --sourcemap=false (soon to be --sourcemaps=false

Compare your experience.

Observations

I believe that in the typical dev/test cycle, the programmer changes a single test file 80% of the time, the corresponding application file 10% of the time, and hardly anything else the remaining 10%.

My sense is that it would be wise to optimize for this workflow.

[tmansson]

I reported this in #5334. Do you have any idea why serve/build is different than test?

[Meligy]

With the default reporters and browser you should be seeing in console and browser, not completely hung.

The compilation experience is bad for me too (feels slower than ng build --watch), but not as horrible as described. Could be hardware or project size though (mine has over 180 tests still).

One workaround I use to speed that is to use fdescribe() or fit() to run only the test(s) you are modifying, saving a bit on the post-build times.

Often requires being careful though not to commit these. There are some 3rd party tslint rules that make that break the build, I'm considering adding one to my project.

[hccampos]

In our project it is extremely slow at first and then actually crashes due to node running out of memory (tries to go over 2GB or thereabouts).

[filipesilva]

Due to the way our karma setup work, we can't use a vendor chunk in unit tests as we use in serve/build since karma-webpack does not support it.

This slows down rebuilds and causes them to take a long time on chunk asset optimization due to processing sourcemaps.

@TheLarkInn has suggested using the DLLPlugin in unit tests, since he has seen similar setups with a lot of success.