Client Side Testing with Mocha never done()


Realized that a subscriptions test is something a little different than just doing a client side test. It can’t use stubs because that wouldn’t be testing the ability to get the client data from the server. Right?
So there’s a couple paths. I could separate the functions in the methods.js file out into something that’s also exportable which I can gracefully use in the subscriptions.test and continue using stubs, or I try to go the route I was going before which is without stubs.

I’m practiced at building with Meteor in 1.2 without any testing. Now I’m I’m stepping through the new Meteor 1.3 Guide and expanding the “react-simple-todos” tutorial with methodology from the guide. My goal by the end of it is to have exercised my learnings from the tutorial and end with a boilerplate and example-app for large scale meteor app building with react.

I’m working on Mocha/BDD Testing now, and I have succeeded in building some server side tests (methods.tests.js and server/publications.tests.js) but testing the API for subscriptions introduced a new challenge - client side testing with mocha.

Directory imports/api/tasks

From subscriptions.tests.js

  const userId =;
  const task = {
    text: 'test task',
    createdAt: new Date(),
    owner: userId,
    username: myUsername,

  beforeEach(function() {

  it('can find public task', function(done) {
    Tasks.insert(task); // Create Public Task
    let privateTask = task;
    // Test should fail if private=false
    privateTask.private = false;
    Tasks.insert(privateTask); // Create Private task'tasks.find.public', (err, res)=> {
      try {
        console.log("Results> ", res);
        assert.equal(findPublic().count(), 1);
      } catch(err) {


Tasks : subscriptions :  can find public task ‣
Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.
    at packages/practicalmeteor_mocha.js?hash=489e07e2e98906b5ed07059bc93d8f53fe79c00b:3127:19


I would try logging just before the statement to make sure that the code executes at least that far. Does the console.log("Results> ", res) ever fire?