On my server side
let func1 = () => {
let current = Meteor.userId() || 'System'
// do crazy stuffs and update mongo
return "bla"
}
Meteor.methods({
"Domain.func1": () => func1()
})
How can i test func1
?
it('...', function() {
let result = func1() // give exception because Meteor.userId must be inside Meteor.call, using this.userId instead ...
})
Please note that the Meteor.userId
is in a more complicated situation in the project and cannot inject from outside (For example, I extends all the MongoCollection and put the Meteor.userId
before saving)
How can i test the response inside callback of Meteor methods ?
it('...', function() {
Meteor.call("Domain.func1", function (err, res) {
assert.equal(res, "bla") // this never fires when running the test
expect(res).to.equal("bla") // does not run
throw "Evil" // this does not fire neither
})
})
I am using Meteor 1.4
and dispatch:mocha
. I think the callback is not running under the scope of the test, thus the assert
is ignored. What is the proper way to write unit test in this situation ?
Pump ? anyone ? No one ever wrote unit tests with Meteor O_O ?
I can’t say I understand your use of arrow functions, and I’m wondering if your methods are even working the way you’d expect? If you put a console.log inside of func1, do you even see it when you run your test suite?
Although I use validated-methods, I can confirm that unit tests with mocha work as expected.
Thank for your reply. Yes, the function works. Actually, we have the project running on production right now
So do you see the console log in a test run?
Are you using chai for evaluation? I’d expect to see things prefaced with chai
, like chai.assert.equal(res, "bla")
? But I’d also expect assert to throw an undefined, unless you are defining it outside of your tests somewhere?
the assert
will work if it outside of the callback. Please have a look at the end of the question. I just updated it so other will easy to follow
That is kind of what I was getting at with my first comment – I don’t understand how you are getting the return callback from your (presumably) client side call. If you switch to a definition like this, I think you’ll keep your scope:
Meteor.methods({
"Domain.func1": func1(),
});
But then, why not just put the body of func1
inside the method definition?
But then, why not just put the body of func1 inside the method definition?
well, It is simple as we want to separate the logic outside of the interface, so we can have more thing to do with the logic, for example, interceptors with higher order functions.
The meteor method works flawlessly and return the expected value (as it is running on production now). It is just the matter the scope of the callback is outside as always