How to test a custom Meteor method with Velocity + Jasmine [closed] - meteor

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a Collection 'workouts' as follows:
Workouts = new Mongo.Collection('workouts');
Meteor.methods({
workoutInsert: function () {
var user = Meteor.user();
check(user._id, String);
var workout = {
completed: false,
createdAt: new Date(),
userId: user._id
};
var workoutId = Workouts.insert(workout);
return {
_id: workoutId
};
}
});
I am wondering:
1) What would a Velocity + Jasmine test look like for this method? I'm unsure where to start and would really appreciate and example!
2) Is this the best practice to define this method and call it client-side? Or perhaps should I create a Workout class and add call this method from an instance method of that class? Or should I perhaps extend Workouts to be it's own class and add instance methods to that?

Answer 1

In Meteor there is several types of testing: Client Integration, Client Unit, Server Integration and Server Unit.
Integration tests mirror your site and will load in your Meteor methods for you(ie. workoutInsert).
If I were testing this, I might have something such as:
//File Location: app/tests/server/integration/workoutsSpec.js
Jasmine.onTest(function () {
describe('workouts', function () {
it("should call to Workouts.insert",function(){
//Make user return truthy _id for testing
Meteor.user() = function(){return {_id : "1";}}
//Setup a spy to watch for calls to Workouts.insert
spyOn("Workouts",insert);
//Call workoutInsert Meteor Method
Meteor.call('workoutInsert');
//Verify if Workouts.insert was called
expect("Workouts.insert").toHaveBeenCalled();
});
});
});
Lastly, MeteorJS gives you a lot of freedom as to how you implement things and there's no clear best way to do things that works for every scenario. Although, I'd advise against placing any code that interacts with your database on your client. Anything located in your client folder is publicly accessible/readable to your users( Do they need to see low level validation details?).

Answer 2

To answer your second question, the best practice is to keep your Meteor methods isolated on the server directory. Meteor uses these reserved directory names to give you control over resources that are served to the client, server, or both. You don't need to have them in the same file or directory as your Mongo collections, as all your collections can be available on both client and server. This is usually considered the best practice, especially if you're using frameworks like angular-meteor which rely on Collection definitions being available on the client, so that filters can be passed to them. You can secure and modify permissions for these Collections on the using collection.allow()/deny()
So if you kept all your collections in the collections/ directory they could be defined like so:
Workouts = new Mongo.Collection('workouts');
would be the contents of collections/workouts.js
Then, in your server/ directory, on the same level as your collections/, you can put all your methods in a file at this level or deeper in the tree, like a server/methods/ directory. Then you can put your methods in a workouts.js in this directory, if you like.
Meteor.methods({
workoutInsert: function () {
var user = Meteor.user();
check(user._id, String);
var workout = {
completed: false,
createdAt: new Date(),
userId: user._id
};
var workoutId = Workouts.insert(workout);
return {
_id: workoutId
};
}
});