Moving Forward with Meteor Testing

Recently the Velocity project was handed back to MDG, which we know are very busy.

This may cause concern for the testability of Meteor but after watching the talk “How to Stop Hating your Test Suite” i’m pretty convinced that this is the way forward for Meteor testing in the next year. Perhaps the built in integration testing will improve soon.

Spoiler alert… In the talk it boils down to writing less integration tests and focuses more on unit tests and end-to-end tests.

Use integration testing sparingly because they make the same exact test test time grow exponentially as your project grows even if that test hasn’t changed (due to setup and teardown).

This means that we’re in pretty great shape actually! Unit tests run very fast because we can run them outside of Meteor & Velocity. Jasmine for example can stub a Meteor.userId and return a value. I’ve done this with 2 projects with a lot of success.

End-to-end testing doesn’t require anything with Meteor so that means you can use anything like Capybara or the new hotness… Chimp.js (cc @sam)


I’m definitely looking to dive deep in to the world of Meteor testing. However I find the community lack a huuuuuuge asset to catalyse this. How to write easily testable code in Meteor. We have a very free stack. React is catching on, and several paradigms are very different from one project to the next. I’m a bit in the blue about what to do here.

Where should one use unit tests, integration tests and E2E. How should code be written to fit in to each of these categories easily? How to write prototyping code with tests in a way that you don’t have to rewrite your tests completely on your next iteration?

A lot of these things are severely missing still, or I simply haven’t found them-

1 Like

Well, that is kind of true - many things about testing have been quite hidden. So let me give you my two cents here:

The bible:

Second, a little faster

Third, the things that allow you to test as you should in Meteor:

Where should one use unit tests

Every piece of logic that can be used as a black/white box anywhere in your application and fulfills a specific objective. Together they allow

integration tests

Is testing all unit tests in a sequence to determine if all actors are playing seamlessly while the piano is playing.

and E2E.

These are the scenario’s that are aimed at use cases and are aimed at the end user - and are quality assurance. An end to end test.

How should code be written to fit in to each of these categories easily?

That depends how you will manage your project.

How to write prototyping code with tests in a way that you don’t have to rewrite your tests completely on your next iteration?

Change is inevitable. This includes refactoring. The only answers to this are:

  1. write no code
  2. don’t change the objective

Everything in between will mean that you have to change code.

Have fun!


The bible will become a bible, when it’s done. Already pre-purchased :smile:

I’ve hit a few snags testing out cucumber, but I definitely like BDD when it comes to Meteor. It just makes sense.

Until the bible has been finished I fear most Meteor devs are still a bit in the dark as to what they should do!


The “bible” is a very small tutorial. Don’t buy it until it’s done (if we come to see this day…).

Once we have true modules in Meteor, you will be able to use standard tools.

I may be wrong, but i think Velocity has no real future.

How about this:

It’s surely me than a tutorial with all the competed theory chapters that explain in-depth the exact questions above; the difference between the test types etc.

I definitely appreciate the time it is taking, it is challenging to write about something that is in flux!

That being said, I’ll let you know that I’m currently working on the CI chapter and doing the chapters in order. Expect that update in the next couple of days.

Out of interest, what would you want know about more than anything else about testing in Meteor?


What would be interesting is perhaps getting two views on testing. One from the single developer trying to test for expected behaviour when comparing to specifications. Tools, methods, focus.
Another from a project group perspective. A more enterprise approach. And their difference in tools, methods, focus. CI may not be as important for a single dev, but most surely vital for a company delivering a long-lasting product!

This is something I’ve been struggling with as a single dev. What tools are redundant or time-wasters for my use? Is BDD at all worth it for smaller projects? Stuff like that is as important as to how one should actually go about doing it. When is the usefullness cutoff point.

What makes you think Velocity has no future? Do you have a contender for it you think is more suitable across the board?

any workaround how to run unit tests inside packages ?

So the video will go over this a bit more than me but in general I only write integration tests for models and any kind of mission critical piece (which tends to be just a few). I try to unit test everything that’s not super hard to test. Sometimes this means not using anonymous functions.

Learning functional programming will lead to easier to unit test code. React has made this paradigm much more popular (which is why React components are so much easier to test than other views).

I tend to use Karma outside of Meteor and then load the JS according to the Meteor rules. This setup allows you to TDD (if that’s your jam) because they only take a few hundred MS to complete (focusing on one module/func is key).

I write e2e tests after the prototyping phase is over… ideally this rapid changing is done in wireframes but if not once it settles I write them. I’ve just re-wrote my old tests in Cucumber using ChimpJS and it’s been really fast and easy to setup so far.

I just add them to my karma config using the file matches and it seems to work well for me. However, I tend to write modules instead of packages anyhow.