Running tests in browser is very very slow about jasmine-rails

[searls]

Unfortunately, I can't think of anything off-hand to help here. If I were experiencing what you are, I might start by opening bundle open jasmine-rails and sticking a debugger in the jhw adapter code to observe how and how often it's getting called and how long it's taking.

[rymohr]

Load takes ~ 45s, tests take ~ 1s. And the load takes this long regardless of whether any files have been modified or not.

I split my code into two separate index files to try and speed things up (everything under lib and vendor goes into support.js, everything under app goes into application.js). Didn't seem to make any difference.

[rymohr]

Thanks @searls, I'll give that a try.

[searls]

In general I was pretty pessimistic about sprockets caching, so it's
very possible that I went too far and there's a configuration
available to make it cache assets for you.

[seeflanigan]

Is it caching nothing? Would there be a way to find out how much time is compiling/loading CS/JS/Tests vs CSS/other assets? Might it be possible to cache everything but the JS files?

I say this without much context around Sprockets... so, with a grain of salt, as we do.

[searls]

I presume based on his config that he has a lot of JS that takes a long time to compile. My guess is we're forcing a total re-compile by either having thrown sprockets into debug mode or explicitly disabling it altogether. I'm not particularly surprised by this behavior, but I bet we could do better.

[seeflanigan]

"I bet we could do better"

I would "Like" that comment if GitHub supported the functionality.

[rymohr]

Yeah, we have a very large javascript codebase (on the order of hundreds of thousands of lines altogether).

I figured the .jhw-cache folder would be a good place to sort this out. Turns out the browser version doesn't use this folder at all.

I took a look at the source for jasmine-webkit-headless and :enable_cache is true by default. Not sure why the .jhw-cache folder wouldn't be used in that case.

[rymohr]

I'll let you guys close the issue after confirming the fix.

[sinisterchipmunk]

+100 -- I'm testing a WebGL application, which is not supported from the command line. I couldn't stand it any more and had to see if anyone else was experiencing this. The above commit fixed my problem.

[seeflanigan]

Merged. Thanks very much!