Test development cycle is slow unless sourcemaps are turned off #5423

wardbell · 2017-03-14T19:02:50Z

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.

Open a CLI project with tests.
Develop tests in a single spec file with ng test, changing frequently.
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.

The text was updated successfully, but these errors were encountered:

bialad · 2017-03-15T09:03:02Z

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

Meligy · 2017-03-16T02:10:16Z

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 · 2017-03-16T05:46:10Z

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 · 2017-03-18T00:07:50Z

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.

Blocked by angular#5500 Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Fix angular#5332 Fix angular#5351

Blocked by angular#5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Fix angular#5332 Fix angular#5351 BREAKING CHANGE: The top level `files` and `include` options of `src/tsconfig.spec.json` should be removed. The `src/typings.d.ts` file should be modified to contain the following: ``` /* SystemJS module definition */ declare var module: NodeModule; interface NodeModule { id: string; } ``` Projects using TypeScript 2.0 or TypeScript 4.0 while NOT using tsconfig inheritance need to update the following files: - `src/tsconfig.app.json` - `src/tsconfig.spec.json` - `e2e/tsconfig.e2e.json` By adding the following entry to `compilerOptions`: ``` "typeRoots": [ "../node_modules/@types" ], ```

Blocked by angular#5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Fix angular#5332 Fix angular#5351 BREAKING CHANGE: Related to TypeStrong/ts-node#283 The `src/typings.d.ts` file should be modified to contain the following: ``` /* SystemJS module definition */ declare var module: NodeModule; interface NodeModule { id: string; } ```

Blocked by angular#5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Related to TypeStrong/ts-node#283 Fix angular#5332 Fix angular#5351 BREAKING CHANGE: The following files need changes: - `src/tsconfig.spec.json`: remove `files` and `include` entries. Add `"dom"` to the `lib` array. - `src/typings.d.ts`: replace ``` declare var module: { id: string } ``` with ``` declare var module: NodeModule; interface NodeModule { id: string; } ```

Blocked by angular#5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Related to TypeStrong/ts-node#283 Fix angular#5332 Fix angular#5351 BREAKING CHANGE: The following files need changes: - `src/tsconfig.spec.json`: remove `files` and `include` entries. Add `"dom"` to the `lib` array if not using tsconfig inheritance. - `src/typings.d.ts`: replace ``` declare var module: { id: string } ``` with ``` declare var module: NodeModule; interface NodeModule { id: string; } ```

Blocked by angular#5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Related to TypeStrong/ts-node#283 Fix angular#5332 Fix angular#5351

Blocked by angular#5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in angular#5423. Related to TypeStrong/ts-node#283 Fix angular#3911 Fix angular#5332 Fix angular#5351

Blocked by #5500 (fix is included in this PR so that CI will run). Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points. This in turn was hiding errors related to typeRoots lookups. It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile. This might also have contributed to the overall slowness of unit tests in #5423. Related to TypeStrong/ts-node#283 Fix #3911 Fix #5332 Fix #5351

This PR uses a new Karma plugin to enable vendor bundles in unit tests, increasing rebuild performance. On a medium size project rebuilds times were 15x smaller (16.5s to 0.9s). Fix angular#5423

This PR uses a new Karma plugin to enable vendor bundles in unit tests, increasing rebuild performance. On a medium size project rebuilds times were 15x smaller (16.5s to 0.9s). Fix #5423

This PR uses a new Karma plugin to enable vendor bundles in unit tests, increasing rebuild performance. On a medium size project rebuilds times were 15x smaller (16.5s to 0.9s). Fix angular#5423

angular-automatic-lock-bot · 2019-09-07T02:41:20Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

wardbell mentioned this issue Mar 14, 2017

build(aio): yarn test --sourcemap=false for faster dev/test cycles angular/angular#15151

Merged

3 tasks

filipesilva mentioned this issue Mar 18, 2017

ng test much slower than ng build/serve #5334

Closed

filipesilva added command: test labels Mar 18, 2017

filipesilva mentioned this issue Mar 18, 2017

fix(@angular/cli): fix test typings #5504

Merged

This was referenced May 4, 2017

feat(@angular/cli): improve unit test performance #6160

Merged

It takes forever in "92% chunk asset optimization" can it be cached or disabled? #5775

Closed

filipesilva closed this as completed in #6160 May 8, 2017

kahboom mentioned this issue Oct 19, 2017

Unit tests, ignore sourcemaps syndesisio/syndesis-ui#1118

Closed

angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test development cycle is slow unless sourcemaps are turned off #5423

Test development cycle is slow unless sourcemaps are turned off #5423

wardbell commented Mar 14, 2017 •

edited

bialad commented Mar 15, 2017

Meligy commented Mar 16, 2017

hccampos commented Mar 16, 2017

filipesilva commented Mar 18, 2017 •

edited

angular-automatic-lock-bot bot commented Sep 7, 2019

Test development cycle is slow unless sourcemaps are turned off #5423

Test development cycle is slow unless sourcemaps are turned off #5423

Comments

wardbell commented Mar 14, 2017 • edited

Bug Report or Feature Request (mark with an x)

Versions.

Repro steps.

Observations

bialad commented Mar 15, 2017

Meligy commented Mar 16, 2017

hccampos commented Mar 16, 2017

filipesilva commented Mar 18, 2017 • edited

angular-automatic-lock-bot bot commented Sep 7, 2019

wardbell commented Mar 14, 2017 •

edited

Bug Report or Feature Request (mark with an `x`)

filipesilva commented Mar 18, 2017 •

edited