Writing tests for meteor applications

testing
1

Hello everyone.

I’ve written a few apps with meteor. But I haven’t been able to write tests for any of them so far. The problem is simple: I don’t know where or how to begin. Can someone recommend some starting point for me (resources or otherwise)? Thanks.

2 Likes
2
1 Like
3

I don’t like any of the official unit testing strategies for Meteor tbh. I prefer to use Jest for my unit tests, and just stub out the Meteor internals using an approach like this https://blog.meteor.com/real-world-unit-tests-with-meteor-and-jest-3d557e84e84a

for integration tests I like Chimp, 2.0 is coming soon but 1.0 has been renamed to Chimpy https://thebrainfamily.github.io/chimpy/

2 Likes
4

I don’t know if its just me or if it’s the case with most other devs. Testing is one topic where I wrack my brain a lot. I’m almost always at a loss for what to test, what to mock/and how, how much test to write etc.

Today I decided to write some tests for a simple meteor + React app I built that’s already in Google play store.

Setup was hell. I explored Mocha, chai, jsdom, enzyme, babel, we pack etc. Getting a working configuration took me more to six hours. The whole day. But I did end up with a working config.

But now one of my components needs to read from a file that’s supposed to come from a network request and I’m stuck.

I’m getting frustrated with testing.

2 Likes
5

Setup was hell. I explored Mocha, chai, jsdom, enzyme, babel, we pack etc. Getting a working configuration took me more to six hours.

This is why I always prefer Jest, it bundles mocha and karma and just works together with zero config. It’s the easiest way to test IMO.

But now one of my components needs to read from a file that’s supposed to come from a network request and I’m stuck.

Then you should be mocking out whatever gets that file from the network. For example if you have a class with a method like myClass.fetchFileFromNetwork(), you would want to mock it in your test like this:

import { myClass } from './my-class';
import { someMethodToTest } from './some-file';

it('tests something', () => {
   // replace the method with a fake mock using jest.fn()
   myClass.fetchFileFromNetwork = jest.fn(async () => {
       // mock whatever return value, for example if it returns a json object you can return a fake one here
      return { a: 1, b: 2 };
   });
   // call the method you're testing, which internally calls myClass.fetchFileFromNetwork
  someMethodToTest();
  // then if you want to you can assert the method was called
  expect(myClass.fetchFileFromNetwork).toHaveBeenCalledTimes(1);
  expect(myClass.fetchFileFromNetwork).toHaveBeenCalledWith('whatever', 'arguments', 'you', 'expect')
});

unit testing is one of those things that will make more sense as you do it more until it becomes really easy. I’d suggest picking up a good book on the topic

4 Likes
6

It is a royal pain, and I have not liked any of the “new” testing suggestions that have emerged… I still stick to 'ol jasmine.

Try my scaffolding tool, maka-cli

 $ npm i -g maka-cli

Then create an app:

 $ maka create TestApp --test=jasmine

Then, run:

 $ maka --test

May not help you directly with your current app, but you could peak at my baseline…

Also supports mocha:

 $ maka create TestApp --test=mocha
2 Likes
7

Any suggestions? Keen on learning this.

And as I wrote here - I’m keen on creating a resource for Meteor testing as I blunder my way into getting tests up for my apps. It was a bump on an old thread and didn’t receive as much encouragement as I had hoped so I haven’t made steps to do this yet…

8

Any suggestions? Keen on learning this.

There are so many good books and authors. Eric Elliott has written some great ones and has a good Medium blog https://medium.com/javascript-scene/tdd-the-rite-way-53c9b46f45e3

I’m keen on creating a resource for Meteor testing as I blunder my way into getting tests up for my apps

Technically this is the official Meteor testing guide https://guide.meteor.com/testing.html

9

Ah, our latest pain point. Be prepared for a lot of pain if you want to add proper testing to Meteor (see our recent questions on Mocking/Stubbing/Spy Mocking ES6 module dependencies).

The strategy setup in the Meteor guide is more theoretical and will only work for integration tests (meaning that your function that you test isn’t calling any other function). As soon as you have to stub or mock something, you will find out that it’s not working (well, as of end of last week we finally have a working solution Using sinon.spy to track callCount always returns 0 on nested functions).

But for integration tests on the backend (most examples you find will be for frontend where also Meteor seems to focus on) it’s difficult. Loading of a database is difficult (needs to be in a special format to load a MongoDb which is then artificially increased in size a couple of times).

We haven’t started with any E2E test involving both front- and backend.

We’ve tried any tool on the planet, we’d love to get Wallaby going (again, see our threats on that topic Wallaby.js on 1.8 Broken) but it ended up with Meteor saying Wallaby should invest time and Wallaby saying they have no specific Meteor knowledge so MDG should invest time. Guess what, we can’t use it though if it would be working it would be a great step forward.

In summary, proper testing isn’t possible with Meteor IMO. Again, to me that’s a turnoff point for any serious small business out there.

Those open pain points should be addressed with top priority IMO as testing is a basic requirement for any serious app that is used in production (like as MongoDb multi-document transactions, see https://forums.meteor.com/t/has-anyone-got-multi-document-acid-transactions-to-work-in-meteor/47427).

But it’s obviously MDG’s decision where they put the resources. But the current way where they concentrate their time & resources on isn’t helping attracting and more important, retaining business customer (and when I say business customer I don’t mean AirBnb who can easily throw some 20 developers at something that isn’t working and develop their own solution)!

1 Like