I'm trying to test simple frontend code. I just want to check with mocha that myModule is object and keys length greater then 0.
Module definition:
var myModule = (function () {
return {
option: false
};
})();
I'm trying to do so:
var expect = require('chai').expect;
var myModule = require('<path_to_my_moule_file>');
describe("myModule", function() {
it("is myModule object", function() {
expect(myModule).to.be.a('object');//I know it's not enough
});
it("is myModule not empty", function() {
expect(Object.keys(myModule)).to.have.length.greaterThan(0);
});
});
But of course this didn't work. Because my module isn't a nodejs module I thought, anyway myModule returns simple {}, but not a real value of it (I'm trying strings, etc, but it always {}).
How should I test this kind of code?
Update:
And what if i wouldn't use modules at all?
Tested js file may be very simple:
var Config = {isDev: true};
Is it testable?
Thanks
You could add code like this at the end of your module:
if ( typeof module === 'object' && module.exports) {
module.exports = myModule;
}
A typical browser environment does not have module defined in the global space, so this will export your module if you are running in Node.
Related
When testing with Mocha, how dose one load foo.js so that the foo-test.js can test global variables such as giveMeFive()?
foo.js:
function giveMeFive() {
return 'High five!');
}
foo-test.js:
describe('#convertNumberToDollar()', function() {
it('should get a successful high five', () => {
assert.ok( giveMeFive() === 'High five!', ' successful high five.' );
});
});
It would be ideal if the solution can be automated via Bamboo.
You can just use import * as thisNameDoesntMatter from 'foo' or, using es5 style (which is cleaner in this case), require('foo') and globals defined in that file will be available on the global scope.
For instance, if you define the following JavaScript file:
//test.js
aGlobalVariable = 'someValue';
let aLocalVariable = 'anotherValue';
export default aLocalVariable;
This is the code Babel will generate (using the es2015 preset and the "node" environment):
//test-compiled.js
'use strict';
Object.defineProperty(exports, "__esModule", {
value: true
});
global.aGlobalVariable = 'someValue';
var aLocalVariable = 'anotherValue';
exports.default = aLocalVariable;
As you can see, the aGlobalVariable declaration is kept in the module. As the entire compiled file will be evaluated when it's imported, aGlobalVariable will be available on the global scope whenever you import this module (if you chose the "browser" environment, it would be defined on window). You don't need to explicitly request the globals to be imported.
I'd like require a module and somehow pass in the current module, or something like that, such that the module being required has the properties of the module requiring it.
For example if I have a file I'm requiring:
(function(global) {
console.log(this.exists);
}(this));
And am requiring it like so:
this.exists = "I exist.";
var myFile = require("my-file"); // Somehow make require pass in 'this'.
The file being required should be able to see this.exists since I've passed this into the require function somehow. I'm not sure if this is possible. I would think you would need to fiddle with the different module objects.
The one constraint of this is that the module being required can't have any nodejs specific things, like code to export it on the module. It has to stay the same as the way I've written it.
Edit:
Turns out there is no way to do this exactly the way I want to. There have been some awesome suggestions on how to do this in other ways, though.
I had to do something similar to this once... best way I figured out was through a level of indirection.
Part1:
define(function() {
"use strict";
function init() {
console.log("this = " + this);
}
return init;
});
Part2:
var myFileInit = require("my-file");
var myFile = myFileInit.init.call(this);
Edit: Another possibility
Create a wrapper for the original module:
// my-file-wrapper
define(["my-file"], function(myFunc) {
"use strict";
function init() {
myFunc.call(this);
}
return init;
});
// Elsewhere
var myFileWrapper = require("my-file-wrapper");
var myFile = myFileInit.init.call(this);
Is there way to define global variable which will be available inside some module.
So, if we have module test, and inside test we have files index.js, test1.js, test2.js, can we define variable inside index.js to be available in test1.js and test2.js, but not outside this module?
Exact situation:
So, I am using some npm module and I don't want to require that module every time, but only within one directory, not whole node application, because that can cause problems to me.
test1.js:
exports = test1Module = {
func1: function(...){...},
func2: function(...){...},
func3: function(...){ console.log(test1Module.secretVariable); }
}
index.js:
var secretVariable = "secretValue";
var test1 = require('test1');
test1.secretVariable = secretVariable;
And similarly with test2, but NOT test3..
What you are looking for is namespaces.
Take a look at the following
How do I declare a namespace in JavaScript?
var yourNamespace = {
foo: function() {
},
bar: function() {
}
};
...
yourNamespace.foo();
I'm considering adopting browserify for some of my projects, but would like to make sure that others don't have to use browserify if they want to use the (bundled) code. The obvious way to do this is to both expose the modules exports through module.exports as well as through a window. global. However, I'd rather not pollute the global namespace for those who are requireing the script.
Is it possible to detect if a script is being required? If it is, then I could do something like:
var mymodule = (function() { ... })();
if (isRequired()) {
module.exports = mymodule;
} else {
window.mymodule = mymodule;
}
Note that no matter what, this will be bundled beforehand, so the var mymodule won't be exposing a global. Also, currently I'm using the revealing module pattern, but would be willing to switch to something more appropriate for browserify.
What's the best way to make a module both requireable and <script src=able? Is it best to just expose a global in both circumstances?
There is a good article from Forbes Lindesay explaining how to do standalone builds:
http://www.forbeslindesay.co.uk/post/46324645400/standalone-browserify-builds
The short version, use the standalone option:
browserify beep.js --standalone beep-boop > bundle.js
I'm dealing with the same problem building a library and here is a rought opinion. I think we need to separate first the audiences for a library in few categories:
those who use browserify and NPM
those who will just download a mylib.min.js and use one way or another
AMD (with bower?), might be the third category.
So, for 1 it is easy, you will have a your index.js module:
module.exports = function () { /* code */ }
and your package.json will have a main
"main": "index.js"
Notice I haven't add any window.xx code to index.js.
For 2 I think the best idea is to create a standalone.js
var mylib = require('./index.js');
global.window.mylib = mylib;
This is what browserify should build.
For 3 (if you care about) you can tweak standalone.js as follows:
var mylib = require('./index.js');
if (typeof global.window.define == 'function' && global.window.define.amd) {
global.window.define('mylib', function () { return mylib; });
} else {
global.window.mylib = mylib;
}
Assuming another library hasn't created a global module.exports object, you can simply check for the existence of module.exports
var mymodule = (function() { ... })();
if (module && module.exports) {
module.exports = mymodule;
} else {
window.mymodule = mymodule;
}
Why not just wrap the entire thing with a closure and pass exports as a parameter?
(function (exports) {
// code here
// ...
exports.foo = bar;
})(exports || this);
This way it will also export it to WebWorker scope and other 'windowless' environments.
This is a trivial example that illustrates the crux of my problem:
var innerLib = require('./path/to/innerLib');
function underTest() {
return innerLib.doComplexStuff();
}
module.exports = underTest;
I am trying to write a unit test for this code. How can I mock out the requirement for the innerLib without mocking out the require function entirely?
So this is me trying to mock out the global require and finding out that it won’t work even to do that:
var path = require('path'),
vm = require('vm'),
fs = require('fs'),
indexPath = path.join(__dirname, './underTest');
var globalRequire = require;
require = function(name) {
console.log('require: ' + name);
switch(name) {
case 'connect':
case indexPath:
return globalRequire(name);
break;
}
};
The problem is that the require function inside the underTest.js file has actually not been mocked out. It still points to the global require function. So it seems that I can only mock out the require function within the same file I’m doing the mocking in. If I use the global require to include anything, even after I’ve overridden the local copy, the files being required will still have the global require reference.
You can now!
I published proxyquire which will take care of overriding the global require inside your module while you are testing it.
This means you need no changes to your code in order to inject mocks for required modules.
Proxyquire has a very simple api which allows resolving the module you are trying to test and pass along mocks/stubs for its required modules in one simple step.
#Raynos is right that traditionally you had to resort to not very ideal solutions in order to achieve that or do bottom-up development instead
Which is the main reason why I created proxyquire - to allow top-down test driven development without any hassle.
Have a look at the documentation and the examples in order to gauge if it will fit your needs.
A better option in this case is to mock methods of the module that gets returned.
For better or worse, most node.js modules are singletons; two pieces of code that require() the same module get the same reference to that module.
You can leverage this and use something like sinon to mock out items that are required. mocha test follows:
// in your testfile
var innerLib = require('./path/to/innerLib');
var underTest = require('./path/to/underTest');
var sinon = require('sinon');
describe("underTest", function() {
it("does something", function() {
sinon.stub(innerLib, 'toCrazyCrap').callsFake(function() {
// whatever you would like innerLib.toCrazyCrap to do under test
});
underTest();
sinon.assert.calledOnce(innerLib.toCrazyCrap); // sinon assertion
innerLib.toCrazyCrap.restore(); // restore original functionality
});
});
Sinon has good integration with chai for making assertions, and I wrote a module to integrate sinon with mocha to allow for easier spy/stub cleanup (to avoid test pollution.)
Note that underTest cannot be mocked in the same way, as underTest returns only a function.
Another option is to use Jest mocks. Follow up on their page
I use mock-require. Make sure you define your mocks before you require the module to be tested.
Simple code to mock modules for the curious
Notice the parts where you manipulate the require.cache and note require.resolve method as this is the secret sauce.
class MockModules {
constructor() {
this._resolvedPaths = {}
}
add({ path, mock }) {
const resolvedPath = require.resolve(path)
this._resolvedPaths[resolvedPath] = true
require.cache[resolvedPath] = {
id: resolvedPath,
file: resolvedPath,
loaded: true,
exports: mock
}
}
clear(path) {
const resolvedPath = require.resolve(path)
delete this._resolvedPaths[resolvedPath]
delete require.cache[resolvedPath]
}
clearAll() {
Object.keys(this._resolvedPaths).forEach(resolvedPath =>
delete require.cache[resolvedPath]
)
this._resolvedPaths = {}
}
}
Use like:
describe('#someModuleUsingTheThing', () => {
const mockModules = new MockModules()
beforeAll(() => {
mockModules.add({
// use the same require path as you normally would
path: '../theThing',
// mock return an object with "theThingMethod"
mock: {
theThingMethod: () => true
}
})
})
afterAll(() => {
mockModules.clearAll()
})
it('should do the thing', async () => {
const someModuleUsingTheThing = require('./someModuleUsingTheThing')
expect(someModuleUsingTheThing.theThingMethod()).to.equal(true)
})
})
BUT... jest has this functionality built in and I recommend that testing framework over rolling your own for testing purposes.
Mocking require feels like a nasty hack to me. I would personally try to avoid it and refactor the code to make it more testable.
There are various approaches to handle dependencies.
1) pass dependencies as arguments
function underTest(innerLib) {
return innerLib.doComplexStuff();
}
This will make the code universally testable. The downside is that you need to pass dependencies around, which can make the code look more complicated.
2) implement the module as a class, then use class methods/ properties to obtain dependencies
(This is a contrived example, where class usage is not reasonable, but it conveys the idea)
(ES6 example)
const innerLib = require('./path/to/innerLib')
class underTestClass {
getInnerLib () {
return innerLib
}
underTestMethod () {
return this.getInnerLib().doComplexStuff()
}
}
Now you can easily stub getInnerLib method to test your code.
The code becomes more verbose, but also easier to test.
If you've ever used jest, then you're probably familiar with jest's mock feature.
Using "jest.mock(...)" you can simply specify the string that would occur in a require-statement in your code somewhere and whenever a module is required using that string a mock-object would be returned instead.
For example
jest.mock("firebase-admin", () => {
const a = require("mocked-version-of-firebase-admin");
a.someAdditionalMockedMethod = () => {}
return a;
})
would completely replace all imports/requires of "firebase-admin" with the object you returned from that "factory"-function.
Well, you can do that when using jest because jest creates a runtime around every module it runs and injects a "hooked" version of require into the module, but you wouldn't be able to do this without jest.
I have tried to achieve this with mock-require but for me it didn't work for nested levels in my source. Have a look at the following issue on github: mock-require not always called with Mocha.
To address this I have created two npm-modules you can use to achieve what you want.
You need one babel-plugin and a module mocker.
babel-plugin-mock-require
jestlike-mock
In your .babelrc use the babel-plugin-mock-require plugin with following options:
...
"plugins": [
["babel-plugin-mock-require", { "moduleMocker": "jestlike-mock" }],
...
]
...
and in your test file use the jestlike-mock module like so:
import {jestMocker} from "jestlike-mock";
...
jestMocker.mock("firebase-admin", () => {
const firebase = new (require("firebase-mock").MockFirebaseSdk)();
...
return firebase;
});
...
The jestlike-mock module is still very rudimental and does not have a lot of documentation but there's not much code either. I appreciate any PRs for a more complete feature set. The goal would be to recreate the whole "jest.mock" feature.
In order to see how jest implements that one can look up the code in the "jest-runtime" package. See https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js#L734 for example, here they generate an "automock" of a module.
Hope that helps ;)
You can't. You have to build up your unit test suite so that the lowest modules are tested first and that the higher level modules that require modules are tested afterwards.
You also have to assume that any 3rd party code and node.js itself is well tested.
I presume you'll see mocking frameworks arrive in the near future that overwrite global.require
If you really must inject a mock you can change your code to expose modular scope.
// underTest.js
var innerLib = require('./path/to/innerLib');
function underTest() {
return innerLib.toCrazyCrap();
}
module.exports = underTest;
module.exports.__module = module;
// test.js
function test() {
var underTest = require("underTest");
underTest.__module.innerLib = {
toCrazyCrap: function() { return true; }
};
assert.ok(underTest());
}
Be warned this exposes .__module into your API and any code can access modular scope at their own danger.
You can use mockery library:
describe 'UnderTest', ->
before ->
mockery.enable( warnOnUnregistered: false )
mockery.registerMock('./path/to/innerLib', { doComplexStuff: -> 'Complex result' })
#underTest = require('./path/to/underTest')
it 'should compute complex value', ->
expect(#underTest()).to.eq 'Complex result'
I use a simple factory the returns a function that calls a function with all of its dependencies:
/**
* fnFactory
* Returns a function that calls a function with all of its dependencies.
*/
"use strict";
const fnFactory = ({ target, dependencies }) => () => target(...dependencies);
module.exports = fnFactory;
Wanting to test the following function:
/*
* underTest
*/
"use strict";
const underTest = ( innerLib, millions ) => innerLib.doComplexStuff(millions);
module.exports = underTest;
I would setup my test (I use Jest) as follows:
"use strict";
const fnFactory = require("./fnFactory");
const _underTest = require("./underTest");
test("fnFactory can mock a function by returng a function that calls a function with all its dependencies", () => {
const fake = millions => `Didn't do anything with ${millions} million dollars!`;
const underTest = fnFactory({ target: _underTest, dependencies: [{ doComplexStuff: fake }, 10] });
expect(underTest()).toBe("Didn't do anything with 10 million dollars!");
});
See results of test
In production code I would manually inject the callee's dependencies as below:
/**
* main
* Entry point for the real application.
*/
"use strict";
const underTest = require("./underTest");
const innerLib = require("./innerLib");
underTest(innerLib, 10);
I tend to limit the scope of most of the modules that I write to one thing, which reduces the number of dependencies that have to be accounted for when testing and integrating them into the project.
And that's my approach to dealing with dependencies.