I’m using practicalmeteor:mocha I run the test server with meteor test --driver-package practicalmeteor:mocha --port 3100
My test is this
import { Meteor } from 'meteor/meteor';
import { chai, assert } from 'meteor/practicalmeteor:chai';
describe('Accounts', () => {
describe('accounts.create', () => {
it('Can create a user ', () => {
Meteor.call('accounts.create','demo', 'demo@demo.com', 'demopassword', {})
const newUser = Meteor.users.findOne();
assert.isObject(newUser,'user object was inserted');
assert.deepProperty(newUser,'profile.name','user has a name');
});
});
});
And throws this error
Error: Method 'accounts.create' not found [404] at Server.apply (packages/ddp-server/livedata_server.js:1589:19) at Server.call (packages/ddp-server/livedata_server.js:1559:17) at Context.<anonymous> (server/methods/accounts.test.js:11:11) at run (packages/practicalmeteor:mocha/meteor/src/setup/SetupRunnables.js:113:18)
You could use something like the following to (integration) test user creation (note: is leveraging Mocha’s Promise support instead of using an async done callback):
import { Meteor } from 'meteor/meteor';
import { Accounts } from 'meteor/accounts-base';
import { chai, expect } from 'meteor/practicalmeteor:chai';
import { resetDatabase } from 'meteor/xolvio:cleaner';
describe('Accounts', function () {
beforeEach(function () {
resetDatabase();
});
it('should be able to create a user', function () {
const createUser = new Promise((resolve, reject) => {
Accounts.createUser({
username: 'demo',
email: 'demo@demo.com',
password: 'demopassword',
}, (error) => {
if (error) {
reject(error);
} else {
const newUser = Meteor.users.findOne();
resolve(newUser);
}
});
});
return createUser.then(function (newUser) {
expect(newUser).to.not.be.undefined;
expect(newUser.username).to.equal('demo');
});
});
});
With meteor testing you either do unit test or full app tests.
Unit tests
When you do a unit test, you need to include all the necessary code. With the test flags you chose you are initiating a unit test. To get it to work you will need to include the file that has the method definition in it. See the simple integration test section of the guide notice that it includes the todos and the lists collection definition. In essence the test is completely encapsulated and does not depend upon the rest of the app. I think you may run into trouble trying to make meteor method calls, but the mongo collection calls should work fine.
Full app tests
You may be actually trying to do a full-app type of acceptance test. Full app tests run all of your code. If that is the case you will need to use the --full-app flag. And you will need to write some server code hooks to make all of those server calls, see chimp’s meteor specific features.
Note: the server global variable is only accessible within a mocha test scope & before / after hook scopes and not available within the describe scope.
The meteor testing article is very good. But it is very dense! There are a lot of topics covered in that section.
as a result, tests are all success which is wrong and the output in the console is BEFORE FAIL so it failed after assertion error, but no error is logged anywhere.
This is serious problem, because tests might appear false positives.
My package versions:
it('should fail on async method wrong assertion', function () {
const promise = new Promise((resolve, reject) => {
HTTP.get('http://google.com', (error, result) => {
if (error) {
reject(error);
} else {
resolve(result);
}
});
});
return promise.then(function (result) {
console.log('result',result.statusCode);
expect(1).to.equal(2);
console.log('this message is not printed!');
});
});
The only what get’s printed is result 200 and test passes.
I run tests with command meteor test --full-app --driver-package practicalmeteor:mocha --settings settings-test.json
it('should fail on async method wrong assertion', function (done) {
...
That will give you the proper failure in the console, but not via the web reporter (which is tied to the issue I linked to - https://github.com/practicalmeteor/meteor-mocha/issues/11). So until that gets fully resolved you could wrap your expect calls in a try/catch, and pass any captured error into done. Ugly, but it will work for now: