You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a fairly large code base (dozens of kLocs) and using Jasmine for testing. After upgrading to Jasmine 2 and bumping up the version of grunt-contrib-jasmine, we see a peculiar behaviour when running tests with coverage using grunt-template-jasmine-istanbul.
All tests are finished in about 25 seconds followed by about 60-100 s when PhantomJS process spikes at 100% CPU and nothing seems to be happening. After that period, the coverage results are displayed.
Further investigation revealed that the coverage is tracked in a Javascript in-memory object and sent to PhantomJS through phantom.sendMessage on jasmineDone callback. The size of the in-memory object is huge, about 2 megabytes. This object is then passed to reporters/PhantomReporter.js, whose implementation of stringify is extremely inefficient for large objects.
package.json => grunt-contrib-jasmine": "^0.8.2
We have a fairly large code base (dozens of kLocs) and using Jasmine for testing. After upgrading to Jasmine 2 and bumping up the version of grunt-contrib-jasmine, we see a peculiar behaviour when running tests with coverage using grunt-template-jasmine-istanbul.
All tests are finished in about 25 seconds followed by about 60-100 s when PhantomJS process spikes at 100% CPU and nothing seems to be happening. After that period, the coverage results are displayed.
Further investigation revealed that the coverage is tracked in a Javascript in-memory object and sent to PhantomJS through phantom.sendMessage on jasmineDone callback. The size of the in-memory object is huge, about 2 megabytes. This object is then passed to reporters/PhantomReporter.js, whose implementation of stringify is extremely inefficient for large objects.
Adding a snippet
into stringify function mitigates the issue. Of course, this is only a simple hotfix that works for us. A more generalized solution would be welcome.
The text was updated successfully, but these errors were encountered: