How can I speed up unit tests with 1.3 and Mocha?


#1

I just tried out the new testing with 1.3 on a hello world project and when following the guide for using meteor -p 3005 test --driver-package practicalmeteor:mocha I noticed that it was still slow because the entire Meteor server has to restart. Is there a way to run unit tests without the restart?

Even with a few tests it’s noticeably slower than running Mocha by itself outside of Meteor. So is it best to skip Meteor for unit tests and just use that for integration tests? I was hoping Meteor unit tests could just setup Mocha for me and run the normal JS way.


#2

I know this doesn’t really answer your question, but curious if you checked out https://wallabyjs.com/? Having real-time visual test and coverage info inside of your editor is a game changer. It’s a paid product but it really is superb… reruns only affected tests on each keystroke.


#3

I haven’t used that but it looks pretty nice! They don’t have Emacs support though :frowning:

I’ve been able to speed up unit tests by just running mocha on the CLI and transpiling with babel. As long as they have exports everything works really nice! Still have to look into getting the Meteor stubs to work though.


#4

Have to emphatically endorse Wallaby also. It’s incredible.

No emacs hmm…? I think they have Vim…


#5

I found this thread for the same reason. I was hoping for much faster unit tests than what I’ve achieved so far with meteor test.

@SkinnyGeek1010 Are you still using mocha cli with babel? I’d be interested in knowing more about your experience.


#6

Yep! I’m actually using Jasmine now but same thing. I’m running it through Karma to test multiple browsers and then I also have a script to test the server unit tests with a jasmine-node module with babel baked in. It’s a little more of a chore to tie them all together but doable :thumbsup:

I mainly went with Jasmine because i’m more familiar with it and I really get annoyed with the 20 deps needed to get mocha running where as Jasmine seems to have all the stubbing tools and matchers I need. Getting sub second tests when isolating it to a block or file.

My current setup for testing is:

  • Jasmine for all unit tests (via node-cli or karma)
  • Meteor test for integration (little to none since there is a lot of overlap)
  • End 2 End tests via Chimp
  • ES Lint for making sure bad formatting errors don’t get merged into master

I haven’t had time to re-visit meteor tests for integration but would likely test some of the publications and Meteor methods.


#7

That sounds awesome @SkinnyGeek1010 :slight_smile:

One specific question on this approach: if you import anything that imports meteor package code (e.g. import { Mongo } from 'meteor/mongo'), the code fails to compile with Cannot find module 'meteor/mongo'. Is there any workaround for this? edit: it would be fine to be able stub out package code - it doesn’t have to actually load.


#8

Ah great point! So all of my Meteor code so far is on the global Meteor namespace so I just stub it out as needed. I also try to extract out business logic out into a domain namspace(s) as much as possible so that this isn’t needed as much.


#9

Yeah, I think that’s the best approach.

@tsemana also pointed me to some resources (thanks, Tony!). Meteor Unit Testing with Testdouble.js by @pcorey addresses the issue directly - I’m pretty hopeful that will solve the problem entirely. There is also extensive discussion here.