Reputation: 520
I wish to unit test my Meteor application. I have several client side files with functions that handle some logic and are called by my event handlers. My instinct is to extract these functions into a module that could be required and called by my event handling code, and unit tested independently, but I'm unsure how to do this in Meteor.
After pulling my logic code into a separate file / module, the only success I had getting other files to see it was to expose the module as a global variable. This is described in the Meteor documentation as package scoping for a variable.
Getting this to work required me to turn off 'use strict'
, and generally just didn't feel quite right - I don't need everything in the package to see this file, just the one place it's used, and a unit test.
I understand that packages are a way of encapsulating code, but it seems overblown for this use case.
I did a bit of hunting for enabling more fine grained dependency management in Meteor and found this one, which the author clearly states is no longer maintained.
What is the right way to encapsulate code for use and unit testing in Meteor?
Upvotes: 1
Views: 122
Reputation: 44288
if in a meteor file you have
MyModule = {}
function cantSeeMe() {
}
MyModule.doesStuff =function() {
}
in a test you can access it ( and in other files in meteor )
describe("Modules", function(){
it("should be exposed", function(){
chai.assert.equal(typeof MyModule.doesStuff, 'function');
});
it("should not be exposed", function(){
chai.assert.equal(typeof cantSeeMe, 'undefined');
});
});
this is using mike:mocha
basically, global isn't a bad thing. In more traditional languages like java / C#, classes are globals the provide things to instantiate objects. In javascript, you need some object to be global that provides access to functions, or "classes". What you don't want to do, generally, is introduce functions or variables into the global namespace ( or window ) unless they have a good reason for being there.
Upvotes: 1