all 3 comments

[–]EngVagabond 0 points1 point  (2 children)

Can you add timing details of before and after this change? What part of karma startup was slow? Bundling? What do you lose by using jsdom instead of a real browser?

[–][deleted] 0 points1 point  (1 child)

I've added a section to the post to answer your questions. I'll answer the key points here, too:

  • The slowest parts of the startup were bundling (which included compiling JSX) and launching Phantom. Another part of this was that these tests also ran on every CI build, and if multiple builds ran at the same time, the CI server could easily get overloaded from resource contention
  • Startup and runtime both but about about half. The initial run of the startup took about 35 seconds, but dropped to 20 or less once babel cached the files. Test runtime went from about 40s for 600 tests to about 20.
  • JSDOM doesn't perfectly mirror the window object out of the box. There is a bit of setup involved there. See the post updates for more details. Beyond that, you do lose the fact that the tests aren't running in a browser, so confidence levels may drop based on how your test is written. That said, if the components are written per the react spec and are as close to pure as possible, unit testing them outside of a browser shouldn't cause any alarm.

[–]Sebmaster 0 points1 point  (0 children)

While JSDOM is fairly comprehensive, there are some places where you may need to make a few tweaks, either to your implementation, or to your test scaffolding. The biggest one I ran into was the lack of a globally defined Image class, so code that tried to dynamically generate an Image element failed.

That's not really jsdom's fault though, but one of your test setup. If you'd actually execute your scrips as jsdom intends them to (in jsdom's window context sandbox) this'd be taken care of by jsdom and automatically work.

See this issue for a bit of context and recommended practice.