How I develop Meteorjs apps - part 2. Testing Meteor packages (for humans)

This is the second article in a series: “How I develop Meteor apps”. You can jump to the other articles:

• part 1. Package for everything
• part 2. Testing Meteor packages for humans <- you are here
• part 3. Continuous integration and delivery of your Meteor “package for everything” project.

OK - so you’ve created your first package, wrote some code and now it is time to test how it works. Meteor offers a nice framework for testing packages: TinyTest. But for me it was unlike anything I have used so far (rspec in ruby or mocha/jasmine in js) and I had problems forcing myself to use it.

Fortunately, there is a way to test packages with mocha. In your package.js replace tinytest package (in onTest part of the file) with:

api.use(['mike:mocha-package@0.5.7', 'practicalMeteor:chai@2.1.0_1']);

and you will be able to write tests like this (server test written in coffeescript):

describe "user creation hooks", ->
  subject = () ->
    id = Accounts.createUser(email: ”w@rst-it.com”, password: "secretpass")
    Meteor.users.findOne(id)

  describe "account just created",  ->
    beforeEach -> @user = subject()

    it "sets subscription to basic", ->
      expect(@user.subscription().name).to.equal "basic"

Running tests

How to run tests for a single package:

Meteor test-packages --driver-package respondly:test-reporter package:name

It will run the test reporter under localhost:3000.

You can even run your tests in the terminal:

Meteor test-packages --velocity package:name

If you want to test your package along with developing your app - just use ‘-p’ option to run tests on a port different than 3000 and you will be able to run the app in parallel.

You can also define settings.json file the same way you define it with normal apps.

Packages which will help you test your app

I have been testing my Meteor apps this way a couple of months now and I am very satisfied with the results. Of course, I did face some problems in the beginning but those packages helped me go through:

practicalMeteor:sinon

Stub, spy, mock - these are the things with which it will help you.

xolvio:cleaner

Want to have a clean database before each run? Add this to your package onTest dependency and in beforeEach call: Package['xolvio:cleaner'].resetDatabase()

hausor:test-helpers

These are test helpers I use quite often so I’ve extracted them to an external package. They will allow you to render template to a div and stub Meteor methods.

Summary

Extracting modules to dedicated packages not only gives you a feature oriented structure, but it also allows you to test each functionality in a real isolation from the other parts of the system.

Spoiler alert: if only tests could be run automatically before deploy… wouldn’t it be awesome?

If you want to know how to do this - wait for my next article about Continuous Integration and Continuous Delivery. Subscribe or follow me @wojtek_krysiak and don't miss anything.