Stubbing method in same file using Sinon

Question

I\'m trying to unit test a function in a file while stubbing another function in the SAME file, but the mock is not being applied and the real method is being called. Here\

Answer 1

The method mentioned above (using a factory to collect the functions) works well; however, eslint will not like the use of a variable/function that has not yet been declared. Therefore I would recommend a slight modification:

// my-functions.js
export const factory = {};
export const funcA = () => {
  return facory.funcB();
};
factory.funcA = funcA;
export const funcB = () => true;
factory.funcB = funcB;

// my-functions-test.js
import {factory, funcA, funcB} from './path/to/my-functions';

describe('MyFunctions | funcA', () => {
  test('returns result from funcB call', () => {
    const funcBStub = sinon.stub(factory, 'funcB').returns(false);

    // Test that the function does not throw errors
    let result;
    expect(() => (result = funcA())).not.toThrow();

    // Test that the return value is that of the mock rather than the original function
    expect(result).toEqual(false);

    // Test that the stub was called
    expect(funcBStub.called).toEqual(true);
  });
});

// Don't forget to test funcB independently ;)

The important distinction is to add the functions within the file to the factory as they are defined to avoid break eslint rules. The only case where this could cause issues is if you tried calling one of those functions within the same file before they have all been defined. Example:

// my-functions-1.js
export const factory = {};

export const funcA = () => {
  factory.funcB();
};
factory.funcA = funcA;

// Since the code execution runs from top to bottom, calling funcA here means that funcB has not yet been added to factory
funcA(); // Throws an error since factory.funcB() is not a function (yet)

export const funcB = () => true;
factory.funcB = funcB;

I prefer this technique of using a "collector" to call functions within the same file since it is not always a great idea to create separate files for EACH function that you write. Often, I find that I will create many related utility functions in order to make my code more readable, reusable, and composable; putting each function into a separate file would make the code slightly more difficult to understand since a reader could not see the definitions of these functions without bouncing between different files.