We migrated our project from jasmine to jest couple month ago and now want to add some coverage in our TeamCity CI server. What we noticed is that for jest on a local dev's machine first run (with coverage) takes about 2-2.5 minutes and all consequent runs take about 20 seconds, but in TeamCity it takes about 6 minutes (with coverage) and only 1:30 without coverage. Is there any way to speed up tests with coverage for TeamCity?
It is an known issue [3] that coverage in jest makes running tests slower. However, there is no explanation what cures the issue. Only tip was to try -i flag on running the tests.
My source [2] tells why that flag improves the efficiency of tests all together. The flag disables multiprocessing and on some machines with limited resources (they say) this speeds up efficiency two fold.
My source [1] also tells the version after 22.4.4 has regression in efficiency (significantly slower than 22.4.4) and that was not fixed until article was written.
Also, they recommend in [1] to use Node but not JSDOM because Node is faster.
So, use:
// package.json
"jest": {
"testEnvironment": "node"
}
Hope these rocket speed your tests and you can taggle the loss of speed via coverage option on.
Sources:
[1] https://itnext.io/how-to-make-your-sluggish-jest-v23-tests-go-faster-1d4f3388bcdd
[2] Why does Jest --runInBand speed up tests?
[3] https://github.com/facebook/jest/issues/2586
Try adding the dotnet.cli.test.reporting parameter, which will
bring back to the normal running time.
Another possible workaround is to use vstest command instead of
test since it supports more precise test adapter path declaration.
Related
My playwright tests are taking the maximum slowMo time to execute certain steps but still execute them. EG:
page.evaluate
elementhandle.innertext
Our playwright.properties file is set to 500ms -
Each of the above steps takes around 502ms for me
If I ask a colleague who uses the EXACT same config from the same master branch, to run the same test, their steps take around 1-2ms
If I reduce slowMo to 0ms, my tests run perfectly fine and each step takes around 1-2ms
I've attempted to reinstall playwright and node modules in order to fix it, but no cigar.
I'm using an M1 Mac with 32GB RAM 16" screen
Had anyone else seen this or have any suggestions?
Our react project has ~3000 jest tests. Most of them are just typical "render without crashing".
When we run npm test, the amount of memory used slowly climbs all the way to 22 Gb.
On machines with only 16 Gb, the tests grind the entire machine to a halt and take a very long time to finish.
What we have tried that has not worked or made the issue worse:
--maxWorkers=50% or --maxWorkers=4 etc
--runInBand (way too slow)
--detectLeaks (half our tests have memory leaks according to this experimental option, but we have no idea what they are or even if they are the cause of this problem)
The only thing that works is running the tests on a machine with a large amount of RAM (>= 32Gb).
Any idea on how we can reduce the amount of memory used by these tests?
We worked around this problem by splitting up the testing in multiple steps.
For example, if you have two source folders:
a/
b/
Then instead of running npm test, you can run it in two steps:
react-scripts test src/a && react-scripts test src/b
This will clear the memory used in each step.
In an effort to debug a production Angular issue, I'm trying to generate a source map for the project. As suggested on a number of SO articles I'm doing as below:
export NODE_OPTIONS=--max-old-space-size=2048
ng build --prod --sourcemaps
The choice of 2G RAM in the first line above is based on the fact I'm running this under VirtualBox on a laptop that I need to run other stuff on. It seems it's decided to steal a few gig of swap over and above that anyway, the HDD activity light has barely been off since the build started ...
The ng build process has been running for about 14 hours now, with practically that entire time having been stuck on this line:
69% building modules 1392/1397 modules 5 active ...b/node_modules/chartjs-color/index.js
This isn't a remarkably big project, how on earth is it taking this long?
I'll add that I don't really know Angular, just looking at this while the maintainer is on leave, so please don't assume I haven't missed anything obvious.
Literally all I want is the source map, not interested in anything else being built. Is there anything I can skip?
Edit:
I followed the one upvoted comment and tried restarting the build - same problem over and over.
Tried checking out to a fresh project and reinstalling node modules locally, as another dev suggested the fact I was checking out production atop of dev branch might be an issue - same.
Tried doubling RAM - same.
What appears to have fixed it is the addition of option --no-aot. But I don't know if that means it's a none-identical build, at least in terms of source map? Will find out I guess ...
I have a Haskell project with 300+ files (mostly auto generated). I can build it in few minutes with my 4 yo. processor (by specifying ghc-options: $everything: -j in stack.yaml) but when it comes to Travis things becomes really slow. It seems that modules being processed sequentially and even single module compilation time much larger (about one second on my machine vs tens on seconds on Travis) Eventually I hit Travis timeout (50 min for single job). Is there any way to speed up Travis build or to split up compilation process to multiple jobs? I would accept paid plan from Travis, I need solution which just works without complex setup.
This configuration uses stages: https://github.com/google/codeworld/blob/f20020ca78fee51afdf6a5ef13eacc6d15c15724/.travis.yml
However, there are unpredictable problems with the cache, or perhaps problems with the Travis config: https://travis-ci.org/google/codeworld/builds/626216910 Also, I am not sure how Travis utilizes the cache(s) for simultaneous builds.
https://github.com/google/codeworld/blob/f20020ca78fee51afdf6a5ef13eacc6d15c15724/.travis.yml#L52-L63 , https://github.com/google/codeworld/blob/f20020ca78fee51afdf6a5ef13eacc6d15c15724/.travis.yml#L74 , and the redundant calls to stack upgrade --binary-only are attempts to work around these issues.
I am investigating the development setup for our next developments.
Requirements
Java, WAR
Javascript, Angular2
JSP, Html, CSS
When doing this with eclipse-neon and nodeeclipse a simple Angular2 "Hello World" will take up giant
100 MBytes, in words hundred megabytes
nearly all is located in "node_modules".
Generating a WAR results in about 30 MBytes after waiting a long time.
Is there a way to reduce this giant footprint to a reasonable size?
As proposed I investigated both ways using webpack with simple "Hello World" apps
First I tried
http://angular.io/docs/ts/latest/guide/webpack.html
. After removing .map-files the total size was 1.1MB. The (packed) WAR comes with 250KB
Second I tried angular-cli. angular-cli creates a set of config-files and a simple "Hello World". After remove .map-files the total size was 3.2MB. the WAR comes with 490KB.
Regarding the size both approaches looks valid. However, we will continue with the first approach since it used explicit config file for webpack. We need to tweak webpack in order to use and support JSP. It is not obvious how this could be done with angular-cli.
If you do not need to tweak the webpack config, you may prefer angular-cli
In fact this is an experience you make when starting with angular 2 and node. The solution to this is using a package builder like "webpack". I'd recommend to create a starter project with "angular-cli"
https://github.com/angular/angular-cli
and start from there to add your project-specific components, libraries, ...
This makes it possible to jump right into development and testing this feature very quickly. Investigating the mighty and complexity behind that is recommended, but can be done step by step.
The command-line commands for this generated project - you can see them defined in the generated "package.json" - provide all you need to develop and run the code
and also
e.g. npm run build:prod
...
preparing the code for deployment, including reducing and packing the code to an absolute minimum size (in my case from ~ 120MB to 2.7MB)