How to access and test an internal (non-exports) function in a node.js module?

The rewire module is definitely the answer.

Here's my code for accessing an unexported function and testing it using Mocha.

application.js:

function logMongoError(){
  console.error('MongoDB Connection Error. Please make sure that MongoDB is running.');
}

test.js:

var rewire = require('rewire');
var chai = require('chai');
var should = chai.should();


var app = rewire('../application/application.js');


var logError = app.__get__('logMongoError'); 

describe('Application module', function() {

  it('should output the correct error', function(done) {
      logError().should.equal('MongoDB Connection Error. Please make sure that MongoDB is running.');
      done();
  });
});

---

The trick is to set the NODE_ENV environment variable to something like test and then conditionally export it.

Assuming you've not globally installed mocha, you could have a Makefile in the root of your app directory that contains the following:

REPORTER = dot

test:
    @NODE_ENV=test ./node_modules/.bin/mocha \
        --recursive --reporter $(REPORTER) --ui bbd

.PHONY: test

This make file sets up the NODE_ENV before running mocha. You can then run your mocha tests with make test at the command line.

Now, you can conditionally export your function that isn't usually exported only when your mocha tests are running:

function exported(i) {
   return notExported(i) + 1;
}

function notExported(i) {
   return i*2;
}

if (process.env.NODE_ENV === "test") {
   exports.notExported = notExported;
}
exports.exported = exported;

The other answer suggested using a vm module to evaluate the file, but this doesn't work and throws an error stating that exports is not defined.

---

EDIT:

Loading a module using vm can cause unexpected behavior (e.g. the instanceof operator no longer works with objects that are created in such a module because the global prototypes are different from those used in module loaded normally with require). I no longer use the below technique and instead use the rewire module. It works wonderfully. Here's my original answer:

Elaborating on srosh's answer...

It feels a bit hacky, but I wrote a simple "test_utils.js" module that should allow you to do what you want without having conditional exports in your application modules:

var Script = require('vm').Script,
    fs     = require('fs'),
    path   = require('path'),
    mod    = require('module');

exports.expose = function(filePath) {
  filePath = path.resolve(__dirname, filePath);
  var src = fs.readFileSync(filePath, 'utf8');
  var context = {
    parent: module.parent, paths: module.paths, 
    console: console, exports: {}};
  context.module = context;
  context.require = function (file){
    return mod.prototype.require.call(context, file);};
  (new Script(src)).runInNewContext(context);
  return context;};

There are some more things that are included in a node module's gobal module object that might also need to go into the context object above, but this is the minimum set that I need for it to work.

Here's an example using mocha BDD:

var util   = require('./test_utils.js'),
    assert = require('assert');

var appModule = util.expose('/path/to/module/modName.js');

describe('appModule', function(){
  it('should test notExposed', function(){
    assert.equal(6, appModule.notExported(3));
  });
});

---

Working with Jasmine, I tried to go deeper with the solution proposed by Anthony Mayfield, based on rewire.

I implemented the following function (Caution: not yet thoroughly tested, just shared as a possibile strategy):

function spyOnRewired() {
    const SPY_OBJECT = "rewired"; // choose preferred name for holder object
    var wiredModule = arguments[0];
    var mockField = arguments[1];

    wiredModule[SPY_OBJECT] = wiredModule[SPY_OBJECT] || {};
    if (wiredModule[SPY_OBJECT][mockField]) // if it was already spied on...
        // ...reset to the value reverted by jasmine
        wiredModule.__set__(mockField, wiredModule[SPY_OBJECT][mockField]);
    else
        wiredModule[SPY_OBJECT][mockField] = wiredModule.__get__(mockField);

    if (arguments.length == 2) { // top level function
        var returnedSpy = spyOn(wiredModule[SPY_OBJECT], mockField);
        wiredModule.__set__(mockField, wiredModule[SPY_OBJECT][mockField]);
        return returnedSpy;
    } else if (arguments.length == 3) { // method
        var wiredMethod = arguments[2];

        return spyOn(wiredModule[SPY_OBJECT][mockField], wiredMethod);
    }
}

With a function like this you could spy on both methods of non-exported objects and non-exported top level functions, as follows:

var dbLoader = require("rewire")("../lib/db-loader");
// Example: rewired module dbLoader
// It has non-exported, top level object 'fs' and function 'message'

spyOnRewired(dbLoader, "fs", "readFileSync").and.returnValue(FULL_POST_TEXT); // method
spyOnRewired(dbLoader, "message"); // top level function

Then you can set expectations like these:

expect(dbLoader.rewired.fs.readFileSync).toHaveBeenCalled();
expect(dbLoader.rewired.message).toHaveBeenCalledWith(POST_DESCRIPTION);

---

I have found a quite simple way that allows you to test, spy and mock those internal functions from within the tests:

Let's say we have a node module like this:

mymodule.js:
------------
"use strict";

function myInternalFn() {

}

function myExportableFn() {
    myInternalFn();   
}

exports.myExportableFn = myExportableFn;

If we now want to test and spy and mock myInternalFn while not exporting it in production we have to improve the file like this:

my_modified_module.js:
----------------------
"use strict";

var testable;                          // <-- this is new

function myInternalFn() {

}

function myExportableFn() {
    testable.myInternalFn();           // <-- this has changed
}

exports.myExportableFn = myExportableFn;

                                       // the following part is new
if( typeof jasmine !== "undefined" ) {
    testable = exports;
} else {
    testable = {};
}

testable.myInternalFn = myInternalFn;

Now you can test, spy and mock myInternalFn everywhere where you use it as testable.myInternalFn and in production it is not exported.

---

I have been using a different approach, without any dependencies: Have a __testing export with all the local functions I want to test, which value depends on NODE_ENV, so it's only accessible on tests:

// file.ts
const localFunction = () => console.log('do something');
const localFunciton2 = () => console.log('do something else');
export const exportedFunction = () => {
    localFunction();
    localFunciton2();
}
export const __testing = (process.env.NODE_ENV === 'test') ? {
    localFunction, localFunction2
} : void 0;

// file.test.ts
import { __testing, exportedFunction } from './file,ts'
const { localFunction, localFunction2 } = __testing!;
// Now you can test local functions

---

you can make a new context using vm module and eval the js file in it, sort of like repl does. then you have access to everything it declares.

---

This is not recommended practice, but if you can't use rewire as suggested by @Antoine, you can always just read the file and use eval().

var fs = require('fs');
const JsFileString = fs.readFileSync(fileAbsolutePath, 'utf-8');
eval(JsFileString);

I found this useful while unit testing client-side JS files for a legacy system.

The JS files would set up a lot of global variables under window without any require(...) and module.exports statements (there was no module bundler like Webpack or Browserify available to remove these statements anyway).

Rather than refactor the entire codebase, this allowed us to integrate unit tests in our client-side JS.

---

Essentially you need to merge the source context with the test cases - one way to do this would be using a small helper function wrapping the tests.

demo.js

const internalVar = 1;

demo.test.js

const importing = (sourceFile, tests) => eval(`${require('fs').readFileSync(sourceFile)};(${String(tests)})();`);


importing('./demo.js', () => {
    it('should have context access', () => {
        expect(internalVar).toBe(1);
    });
});

---

eval doesn't really work on its own (it will only work with top-level function or var declarations), you can't capture top-level variables that are declared with let or const into the current context with eval, however, using a vm and running it in the current context will allow you to access all top-level variables after its execution...

eval("let local = 42;")
// local is undefined/undeclared here

const vm = require("vm")
vm.runInThisContext("let local = 42;");
// local is 42 here

...although declarations or assignments in the "imported" module could clash with anything already declared/defined in the current context by the time the vm starts if they share the same name.

Here's a mediocre solution. This will add a small bit of unnecessary code to your imported modules/units however, and your test suite would have to run each file directly in order to run its unit tests in this manner. Running your modules directly to do anything but its run unit tests would be out of question without even more code.

In the imported module, check if file is the main module, if so, run tests:

const local = {
  doMath() {return 2 + 2}
};

const local2 = 42;

if (require.main === module) {
  require("./test/tests-for-this-file.js")({local, local2});
} 

Then in the test file/module that imports the target module:

module.exports = function(localsObject) {
  // do tests with locals from target module
}

Now run your target module directly with node MODULEPATH to run its tests.

---