Testing server function

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?

I think so

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