Love it! Very concise solution!
Mantra also uses a very smart way of injecting dependencies and mocking Meteor packages concisely, but your solution is more intuitive to work with, especially for apps that are not laid out using mantra’s architecture.
@sanjo’s work on configuring Wallaby is also excellent work definitely, but I feel it’s a little intimidating to digest.
@voiceup Totally understand that it’s intimidating, I still have trouble reading it!
With regards to proxyrequire, another (untested) option might be to use testdouble.js, which has a much terser syntax than sinon + proxyrequire.
Just adding some food for thought here
Very interesting library. Thanks for sharing!
I was trying to test it out, but couldn’t get it working correctly. I think the reason is It doesn’t work with external commonjs modules. But I like how the author is trying to tackle some of the challenges and inconveniences with sinonjs.
@sam testdouble is looking very nice indeed. But it’s exactly as @voiceup is saying. “It (td.replace) doesn’t work with external commonjs modules”.
*edit; let’s hope they are willing to reconsider this decision.
*edit 2; this appears not to be true. See my comment below.
Most of the bootstrap code in the wallaby_server.js is from the boot.js script that Meteor uses to to start the app. I have just modified it, so it only loads Meteor packages.
(I still need to update the wallaby_server.js to use the latest version of boot.js)
I found out testdouble can be used after-all by using a require statement instead of an import. I did not realize at first, because in my understanding babel would have compiled import statements to require statements behind the scenes. And although this is true, it appeared that babel also moves the import statements to the top of the file.
Thereby; the import statements are being placed above the td.replace statements; and thereby nothing is being replaced after all.
You can easily verify this by pasting the code below in the babel repl, and see that:
td.replace('meteor/meteor', { Meteor });
import{ post } from '../posts.js';
const { savePost } = require('../post.js');
will be transpiled to:
var _posts = require('../posts.js');
td.replace('meteor/meteor', { Meteor: Meteor });
var _require = require('../post.js');
var savePost = _require.savePost;
So translating the opening post’s example from proxyquire + sinon to testdouble, makes the following test-case:
// tests/post.js - first part
/* eslint-env mocha */
import { expect } from 'chai';
import td from 'testdouble';
const Meteor = td.object(['userId']);
const FlowRouter = td.object(['go']);
td.replace('meteor/meteor', { Meteor });
td.replace('meteor/kadira:flowrouter', { FlowRouter });
const { post, savePost } = require('../post.js');
Note that we use require for the import of ../posts.js to make the replacements work. At first I would have preferred to keep using imports. But on the other hand, now there is a visual indicator of importing files as they are, and importing files with applied replacements.
And the testing itself:
// tests/post.js - second part
describe('posts', () => {
before(() => {
td.when(Meteor.userId()).thenReturn('user_1');
});
after(() => {
td.reset();
});
it('now stubs Meteor packages', () => {
const result = post(
{ title: 'foo', body: 'bar' },
{ type: 'SAVE_POST' }
);
expect(result).to.have.property('userId', 'user_1');
});
it('can spy on Meteor packages', () => {
const result = savePost(
{ title: 'foo', body: 'bar' },
{ type: 'SAVE_POST' }
);
td.verify(FlowRouter.go('/home'));
});
});
You’ll see that these tests get an after method to undo the rewires after the tests have been run. Do not forget this! Mocha will forgive you, but Wallaby will not, as wallaby reuses the node processes.
As wallaby reuses node processes, and can stop a running test script half way the cycle to start it again, because you for example keep typing, it is advised to add the testdouble.reset in your wallaby.setup function. In this way we are sure that no modules are stubbed out before our testfiles are being reloaded. This is in addition to the after method! It’s not an replacement.
// wallaby.js
setup: () => {
require('testdouble').reset();
},
Merging back in a separate conversation that started here: Meteor test very long build times
If I’m understanding things correctly is there still a bit of an issue here, not with the solutions above but in general: It seems like we’re saying it’s fine for the unit tests or the code being tested to import npm modules and use their functionality in the system under test, but you can’t do the same with the meteor modules, instead you have to stub them out?
That makes good sense where those Meteor modules are for things that shouldn’t be tested as part of the code you are unit testing (routing, sending and receiving data from the server etc); it makes complete sense to stub those modules out.
However, there are some Meteor modules that I do want to be tested as part of my unit tests, I’m happy to accept them as black boxes and I want my unit tests to fail if those modules change in some way after I update them.
One example of that is underscore; I don’t want to have to stub out underscore, and even if I did the code I was testing would then stop working unless I faked underscore’s behaviour in some way. I could get round this by using underscore from npm, but then I would be sending two versions of underscore to the browser (I think, because Meteor uses underscore too?). And really, that’s a bit of a hack as effectively now I’m saying saying “it’s OK to use this if it comes from npm, but not from Meteor” which is then a decision based on implementation rather than the requirements for the test.
Essentially, I guess there are Meteor modules that I want to treat like JavaScript’s built-in functions (I wouldn’t stub out toExponential say).
Does anyone else see this as an issue?
I think your reasoning is fine and there are two solutions available to your problem today:
This is one of the symptoms of the separate Meteor package system. It is hard to use Meteor packages in a Node.js context. But Sashko and Zoltan have indicated that they are aware of this issue and Meteor might use NPM in the future.
@Sanjo I’ve been playing with your wallaby_server.js file, and after some struggles I got it to work.
One question though, are you aware that you must use Fibers within your tests? And do you know a way around this?
For example when I try to reset the database in a beforeAll hook, I get the most famous:
“before all” hook: Meteor code must always run within a Fiber. Try wrapping callbacks that you pass to non-Meteor libraries with Meteor.bindEnvironment.
Running the code all in a fiber solves the issue, but I don’t like stuffing up my tests with fibers. Do you know of a way so Mocha does this for you?
Fiber(() => {
//..
}).run();
I haven’t done this for Mocha myself, but here is the related work:
Thanks @Sanjo, JS testing is new to me (.net background) so I’m still getting up to speed on all of this.
Just to double check, do you mean use the 1.3 test runner separately without Wallaby, or is it potentially possible to set Wallaby up to use meteor’s test runner?
Also, would that approach then mean waiting for a Meteor build to see the results of the code changes? That’s what I’m keen to avoid, I’m trying to get to the super fast red-green feedback that I have in nCrunch or when using wallaby on pure JS classes outside Meteor.
If you want to use Wallaby, the Meteor test runner (meteor test) is not an option.
We have what you want working, but it’s not super beginner friendly yet. It lacks some detailed documentation and abstractions to make the code easier to use. Check out what I wrote recently in https://github.com/xolvio/automated-testing-best-practices/issues/27 and also just clone and try the repo. Then try to copy the necessary files and adjust the Wallaby configs to your needs.
If you are willing to pay money, we can also help you with our paid Xolv.io support. I will make the code more easier to use eventually, but currently I have a high priority on a new product, that we develop 
I’m successfully using proxyquire to test my app. Thanks so much @smeijer for writing this up. It’s been a revelation to have instant test feedback.
One caveat I’ve found is that it doesn’t support absolute imports. So something like…
import Foo from `/lib/services/foo`;
…will not work proxyquire. I believe this is because require will only work a relative path so you’ll need to use:
import Foo from `../../services/foo`;
Hey all,
I wrote up a follow-up blog post that summarizes a lot of this work. It describes using Testdouble.js to mock Meteor-style imports.
Check it out and let me know if I missed anything.
Thank you all for your work on this. Have any of you had any luck using testdouble with Wallaby? I tried @sanjo’s wallaby_server, took a bit of reconfig for Mantra, but I never got it to successfully work loading meteor packages.
Thanks for the “credit where credit is due” 
Yes, wallaby is the reason I started to look into this topic. If you follow the steps in my post above, or the blog post of @pcorey, wallaby will work just fine.
Read this post carefully, note the reset and the require part.
About the wallaby_server you’re referring to. It can be done. It needs some reconfiguration, but then you’re able to run Meteor inside your IDE with full wallaby support. It is however way slower than stubbing some methods out like described above. So I wouldn’t recommend this.
The idea of wallaby is instant feedback. Not to wait 1 to 3 seconds for something to happen.
I’ve finally taken the time to get external Meteor unit testing and wallaby (via Atom) all wired up. I’ve tried using both approaches discussed in this thread - 1) mocking all Meteor dependencies with something like testdouble, and 2) loading the Meteor context to leverage Meteor dependencies (and Meteor packages) directly. Here’s a quick breakdown of my findings.
1) Mocking Meteor Dependencies
require and Node’s require cache. I had to add something like the following to my test tear downs to get back to back tests to pass in certain cases:const resolved = require.resolve(
`${__dirname}/${imports}/api/products/server/product_synch.js`
);
delete require.cache[resolved];
2) Loading Meteor Dependencies (Core and Packages)
meteor/* imports if I want to, or leave them in place if I just want the default code to run - super nice!td.replace syntax when importing meteor/* based packages, on both the client and server. I chose to work around this by changing my meteor/* based imports to look like:import { Meteor, ValidatedMethod } from '../../utility/meteor/packages';
where my packages.js looks like:
const meteorRequire = meteorInstall();
export const Meteor = meteorRequire('meteor/meteor').Meteor;
export const ValidatedMethod = meteorRequire('meteor/mdg:validated-method').ValidatedMethod;
...
With this in place I can properly mock all import meter/* package calls via testdouble (on both the client/sever), when I want to.
Summary
It took a bit of sweat, but I’m really glad I invested the time to get this all working. I’m getting MUCH faster unit test feedback now, which is awesome! I’m currently leveraging both approaches on different projects, but for the larger full web-apps I’m working on (not packages), I’m using the second load the meteor context approach. Sure my feedback times are a bit slower with Wallaby, but we’re talking an average of 1-2 seconds for the test/code feedback loop to complete, versus the 7-9 seconds I was seeing with meteor test. I’m also running this on a 4 year old macbook air, so your mileage will likely be much better!
A big, BIG thanks to everyone that has been looking into this and sharing their findings!
That’s really, really helpful @hwillson, many thanks for writing it up. I’ve been working on this again this week too so this is really well timed for me.
It’s reassuring to see someone more experienced also run up against the issues I’d been having with approach 1).
I’m interested in what you needed to change in approach 2 and also did you get chimp running too?
I’d really like to see the Guide cover approach 2 and for that to become an officially supported solution. I’m nervous about going down that path alone as I know I don’t have the knowledge yet to maintain those files if things break (which seems likely as I’m developing on Windows and so things like simlinks aren’t available). I’m beginning to think the best approach may simply to be to switch to a Mac for Meteor dev (although that will be a nuisance for my .net work potentially).