A first implementation of Meteor app testing for 1.3

announce
41

Thanks a lot for fixing documentation. No apologies for that, that’s normal :wink:

Like sam says, I think it’s better or either not excluding tests directory or just excluding the exclude directory. But on the other hand I don’t see any reason why excluding anything, because as a developer, you know that only *.tests.* files are being run, so if you want to create E2E tests, just don’t name them like that and that’s all.

So you can get my point, normally my convention to organise my app and tests like this:

app
├── README.md
├── client
├── collections
├── lib
├── server
└── tests
    ├── e2e
    ├── integration
    └── unit

So as you see, I put my end to end tests with it’s features in tests/e2e folder, and the unit tests in tests/unit, because I think it’s a good practice to keep tests away from source folder. Reasons to keep them away from the source folder is the basic rule of separation of concerns; also, there are teams in which there are developers and QA’s, so keeping tests in other folder help them separate their work better. Last reason is that if you need to distribute somewhere the code for production, you can just exclude the tests folder and really easily you are not distributing any test.

As a final wish, it would be great just to limit the scope of the test with this usage meteor test --driver-package <driver> [options] [folder].

Greetings!

42

+1 for *.specs.js. That’s in keeping with V&V efforts, and a good idea all-around.

As for tests vs exclude, I don’t see any problem with adding exclude, but lets be slow to remove tests. Backwards compatibility. Gotta give people time to do migration. Maybe Meteor 1.5 or 1.6 or later would be a good time to remove it. Otherwise, it becomes a breaking change.

43

Thanks all. I think it’s clear that *.spec[s].* is probably a good idea, I’ll give some thought to adding that.

I’m inclined to agree with @awatson1978 that we should stick with backwards compat and keep excluding the tests/ folders for now. Unfortunately it’s technically quite tricky given the way file inclusion is implemented, to have a rule that excludes a folder, but then includes certain files within it.

That’s why we just decided to keep excluding the tests/ folders in all cases. Hopefully this isn’t too annoying for people and we can iterate on it if it’s too confusing. Let me know what you all think.

4 Likes
44

on one point, annoyingly http://guide.meteor.com/testing.html#driver-packages leads to nothing.

Also when runnning meteor test-app before worked, running meteor test --driver-package avital:mocha now simply runs in circles building for the web.browser in either test or full-app mode.

This is in beta.16 but is replicated in beta.12 also.

Running the app itself works fine.

Any thoughts/ideas? Thanks.

45

I’m having some issue getting things running on beta 12. I’m using the Mantra architecture, if that’s relevant.

I have some functions defined in server/lib/services/import_run_data.js that I’d like to test and an associated test file at server/lib/services/import_run_data.tests.js that I’ve reduced to simply:

import { mocha } from 'avital:mocha';

I’ve run meteor add avital:mocha and can see it in my .meteor/packages. When running meteor test --driver-package avital:mocha I get the following error:

/Users/tim/.meteor/packages/meteor-tool/.1.1.13-beta.12.12e114j++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:267
						throw(ex);
						      ^
Error: Can't find npm module 'avital:mocha'. Did you forget to call 'Npm.depends' in package.js within the 'modules-runtime' package?
    at Object.Npm.require (/private/var/folders/_t/mf0yc4h973vd1_z0nr6r49840000gn/T/meteor-test-run1q30rwy/.meteor/local/build/programs/server/boot.js:178:17)
    at options.fallback (packages/modules-runtime/modules-runtime.js:33:1)
    at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:88:1)
    at meteorInstall.server.lib.services.import_run_data.tests.js (/private/var/folders/_t/mf0yc4h973vd1_z0nr6r49840000gn/T/meteor-test-run1q30rwy/.meteor/local/build/programs/server/app/app.js:9:20)
    at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:176:1)
    at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:82:1)
    at /private/var/folders/_t/mf0yc4h973vd1_z0nr6r49840000gn/T/meteor-test-run1q30rwy/.meteor/local/build/programs/server/app/app.js:13:1
    at /private/var/folders/_t/mf0yc4h973vd1_z0nr6r49840000gn/T/meteor-test-run1q30rwy/.meteor/local/build/programs/server/boot.js:245:10
    at Array.forEach (native)
    at Function._.each._.forEach (/Users/tim/.meteor/packages/meteor-tool/.1.1.13-beta.12.12e114j++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)

I don’t get any errors when running my app normally (I assume the test file code isn’t executed though). Are their issues with my file paths?

46

Yes, this is an issue with the beta.16 release that will be resolved in the next release. Please stick to beta.12 for testing for now, sorry! (you may need to downgrade to version ..._9 of the avital:mocha package though)

47

Where is this link? The current version of the (draft) testing guide is here right now: https://github.com/meteor/guide/blob/testing-modules-content/content/testing.md

48

You need to use 'meteor/avital:mocha' when importing from Atmosphere packages.

49

Argh. Thanks! I have Atmosphere imports all over my app so I knew that but I copied this one from the documentation (I know it’s WIP so you might want to fix that). Thanks again.

50

@tom thanks for this, have backgraded and made progress, hitting other issues but for now this is an advance, will report back if i cannot fix. THANKS as ever for the great work!

51

I don’t know what I’m doing wrong (still) but

import { mocha } from 'meteor/avital:mocha';

or

import mocha from 'meteor/avital:mocha';

Gives me undefined when logging mocha. However, both describe and it are available in the global scope anyway so I can use them fine. I just can’t use the import statement.

If I do something like

import * as foo from "meteor/avital:mocha";

then I can log foo as

{ __esModule: true, runTests: [Function: runTests] }
52

this is under the meteor test --help will have a read of your link, but currently seeing;

Error: A method named '/mochaServerRunEvents/insert' is already defined
W20160312-17:11:36.719(0)? (STDERR)     at packages/ddp-server/livedata_server.js:1545:15

UPDATE

this was because I had practicalmeteor:mocha and avital:mocha added at the same time.

53

I had exactly the same issue @timfletcher .

I got it working too, for anyone else have issues I did:

meteor add avital:mocca
and
meteor add practicalmeteor:chai

After that, these were the extra bits that had been added to .meteor/versions:

avital:mocha@2.1.0_9`

practicalmeteor:chai@2.1.0_1
practicalmeteor:loglevel@1.2.0_2
practicalmeteor:mocha-core@0.1.4
practicalmeteor:sinon@1.14.1_2

tmeasday:test-reporter-helpers@0.2.0

These should be in the .meteor/versions:

practicalmeteor:chai
avital:mocha

And then this unit test ran successfully

import { mocha } from 'meteor/avital:mocha';
import { chai, assert } from "meteor/practicalmeteor:chai";
import { lineValue } from './../../../lib/order-logic'

//// This is what breaks it for me
////const { describe, it } = mocha;


 describe('lineValue', () => {
     it('calculates unit price correctly when values set', () => {
         const orderLine = {
             quantity: 5,
             unitPrice: 3
         };

         const val = lineValue(orderLine);

         assert.isTrue(val === orderLine.quantity * orderLine.unitPrice, 'value was wrong');
     });
 });

It’s the const { describe, it } = mocha; line that seems to stop it working for me.

It’s worth the effort though, look at this!

That’s one happy TDD developer :D, thanks @tmeasday and team for the hard work.

2 Likes
54

Yeah, same issue. Removing that line stops you overwriting the describe and it globals. With your mocha import mocha is undefined so trying to access a property of it throws an error.

1 Like
55

@jeffry take a look at our practicalmeteor.sinon package for dependency injection during unit and integration tests. We added stub and spy factories to it with restoreAll support, so you can restoreAll before / after each test / test suite and start fresh with overwriting whatever you need per test / test suite. Our practicalmeteor.chai package also includes the sinon plugin, so you can assert on calls to whatever function you stubbed.

Since you can overwrite any method / function in javascript (unlike java and other compiled languages), this approach was just easier and faster for us, than following the dependency injection pattern to the letter, and it solves all our testing isolation needs, without any problems, to date.

56

Dropping in late on the discussion, but better late than never :slight_smile: Just wanted to let everyone know that I’m working with Tom to get practicalmeteor:mocha, practicalmeteor:mocha-console-runner and spacejam to work with 1.3, for both meteor test and meteor test-packages.

6 Likes
57

I’m having some problems when I try to run meteor test. I’m using angular2 so I have barbatus:angular2 installed and ecmascript removed and here’s my test file:

import { mocha } from 'meteor/avital:mocha';
import { chai, assert } from "meteor/practicalmeteor:chai";

describe('Test', () => {
    it('should just run', () => {
        assert.equal(5, 5);
    });
});

when I name the file *.tests.js it gives me this error:

W20160313-10:37:07.580(2)? (STDERR) /private/var/folders/zg/3nxlrbcs3ss41bjfwg5yw0mh0000gn/T/meteor-test-run14ae8wl/.meteor/local/build/programs/server/app/server/try.tests.js:3
W20160313-10:37:07.580(2)? (STDERR) import { mocha } from 'meteor/avital:mocha';
W20160313-10:37:07.580(2)? (STDERR) ^^^^^^
W20160313-10:37:07.588(2)? (STDERR) SyntaxError: Unexpected reserved word

if I tried *.tests.jsx, I get:

While processing files with barbatus:angular2 (for target os.osx.x86_64):
   compilers/jsx_compiler.js:19:14: Babel is not defined
   at JsxCompiler.compileOneFile (compilers/jsx_compiler.js:19:14)
   at caching-compiler.js:292:32
   at
   /Users/user/.meteor/packages/barbatus_angular2/.0.8.7.ilc1q9++os+web.browser+web.cordova/plugin.Compilers.os/npm/caching-compiler/node_modules/async/lib/async.js:182:20
   at replenish
   (/Users/user/.meteor/packages/barbatus_angular2/.0.8.7.ilc1q9++os+web.browser+web.cordova/plugin.Compilers.os/npm/caching-compiler/node_modules/async/lib/async.js:317:21)
   at
   /Users/user/.meteor/packages/barbatus_angular2/.0.8.7.ilc1q9++os+web.browser+web.cordova/plugin.Compilers.os/npm/caching-compiler/node_modules/async/lib/async.js:328:15
   at Object.async.forEachLimit.async.eachLimit
   (/Users/user/.meteor/packages/barbatus_angular2/.0.8.7.ilc1q9++os+web.browser+web.cordova/plugin.Compilers.os/npm/caching-compiler/node_modules/async/lib/async.js:221:35)
   at JsxCompiler.processFilesForTarget (caching-compiler.js:277:11)
   at JsxCompiler.processFilesForTarget
   (compilers/ng_caching_compiler.js:17:32)

any thoughts on where I’m going wrong with this? :confused:

maybe @Urigo can help?

58

I suspect @urigo is probably the best person to answer this, but have you tried naming the file x.tests.ts?

59

Apologies to all about the broken import { mocha } line. Going to fix that right now

60

Hey, we just released a practicalmeteor:mocha version that supports meteor test in meteor 1.3 rc1. It includes the changes from avital:mocha. Help us check it out, with both meteor test and meteor test-packages. Here’s how:

meteor test

From your 1.3 app folder:

meteor --release 1.3-rc.1 add practicalmeteor:mocha@2.1.1-rc.1
meteor --release 1.3-rc.1 test --driver-package practicalmeteor:mocha

For full app tests:

meteor --release 1.3-rc.1 test --full-app --driver-package practicalmeteor:mocha

meteor test-packages

In your package.js Package.onTest:

api.use('practicalmeteor:mocha@2.1.1-rc.1');

From your package folder:

meteor --release 1.3-rc.1 test-packages --driver-package practicalmeteor:mocha ./

Let me or @jsep know how it goes.

Support for meteor test in spacejam coming in a couple of days.

10 Likes