Mocking specific function in the same module only for specific tests

[throrin19]

Hello,

I have a question with vi and mocking. I search since 3 days and I found zero response or nothing works like I want.

I have this file :

export const getUserFromDb = (email: string) => {
    // ... complicated function with database connection
}

export const getUserFromCache = (email: string) => {
    // ... simple function with redis call
}

export const getUser(email: string) {
    const user = getUserFromCache(email);

    if (!user) {
        return getUserFromDb(email);
    }

    return user;
}

I have 3 parts of test in my file :

• I test the method getUserFromDb : I mock the database and generate the complexe result to see if all works like I want
• I test the method getUserFromCache : I mock redis part and saw if all returns like I want
• I test the method getUser : I want to mock getUserFromCache and getUserFromDb and show if all are called correctly according the use cases.

I have the problem for the third part. I don't find how to do this. I test vi.spyOn, vi.mock, ... and none works. The first is ignored, the second mock at all cases.

How to do that ?

Thanks in advance

[tushar-sg]

we are facing the same issue with mocking exported functions in the same module.

[geoidesic]

Also same problem here. I tried this (doesn't work):

    vi.mock('~/helpers/Utility.js', async (importOriginal) => {
      const mod: object = await importOriginal()
      return {
        ...mod,
        contestOutcomes: vi.fn((outcome) => contestOutcomes.SUCCESS),
      }
    })

    const spy = vi.spyOn(importOriginal, 'contestOutcomes');

[geoidesic]

This worked for me:

describe('Outcome Router', () => {
  it('should call the success method for SUCCESS outcome', async () => {
    vi.mock('~/helpers/Utility.js', async (importOriginal) => {
      const mod: object = await importOriginal()
      return {
        ...mod,
        // replace some exports
        contestOutcome: vi.fn((outcome) => contestOutcomes.SUCCESS),
      }
    })

    // Import contestOutcomes from the mocked "~/helpers/Constants" module
    const { contestOutcome } = await import('~/helpers/Utility.js');

    const effectProcessor = EffectProcessorFactory({ contest: { result: 1 }, sourceResult: 1 }); // Create an instance of your class
    effectProcessor.process();
    expect(contestOutcome).toHaveBeenCalledOnce();
  });

});

[throrin19]

this does not works :(

[lamlamla]

Any update on this issues? I faced this problem recently an found zero workaround on the internet. Maybe the solution is to just separate functions into different files

[throrin19]

But this logic also breaks the logic of development, and you end up with a huge number of "useless" files just to fit in with the tests, but which lose the interest of the logical functional division.

If adding tests means losing readability in the structure of the code, this has a perverse effect.

With this logic, we very often end up with a file corresponding to a function, so named exports are useless, as are several ES module evolutions.

So two solutions :

First solution: we don't factor any more, and we have a macro function with all the logic inside (and thank you for the readability) but we simplify the testing part because we don't have to mock these sub-parts any more.

The other solution is to write the tests directly in the file in question and not take them out of the file, but this makes things even heavier, and you have to use a well-configured builder to remove these parts of the code (and inclusions) when compiling for the runtime environment.

But then, I don't see the gains introduced with ES modules, given the limitations of mocks for testing.

[sheremet-va]

You can introduce such patterns as dependency injection, restructure your architecture to use classes, or just don't unit test implementation details because it's an anti-pattern.

[throrin19]

But classes or dependency injections are not the responses in all cases (It will to fit with the logic of all the project) and in my case, I have to test that, it's not implementation details, it's with logic and I wan't to verify if it's correct for all possible cases. I don't think I'm the only one with this problem between ESM and mocks in unit testing

[throrin19]

I found how to reorganize, sorry for this long discussion. I mix anti-pattern and other stuffs, I change that to simplify this part and have an anti-pattern function (not tested) and others functions i can test.

[Pencilbox]

I have absolutely same issue, I have to test utils file and some functions included other functions, that could not be mocked :-(
It works just if both functions are properties of the same object, but would be great if vitest could do it also out-of-box. And to spread utils file to multiples files it is obvious not the best idea.
Here is my example that works:

// utils.ts
export const someObject = {
  funA,
  funB
}

export function funA(): string {
  return someObject.funB();  
}

// This function we will try to mock
export function funB(): string {
  return 'calling funB';
}

//utils.test.ts
import * as utils from '@/services/utils.ts'

describe('Test mock function', () => {
  test('Test 1', async () => {
    const spy = vi.spyOn(utils.someObject, 'funB');
    spy.mockImplementationOnce(() => 'calling mock function');
    const responce = await utils.someObject.funA();
    console.log(responce); // <= calling mock function
    expect(spy).toHaveBeenCalledTimes(1);
  })
})

Also works using key word this in the utils file:

// utils.ts
export function funA(): string {
  return this.funB();  
}

// This function we will try to mock
export function funB(): string {
  return 'calling funB';
}

//utils.test.ts
import * as utils from '@/services/utils.ts'

describe('Test mock function', () => {
  test('Test 1', async () => {
    const spy = vi.spyOn(utils, 'funB');
    spy.mockImplementationOnce(() => 'calling mock function');
    const responce = await utils.funA();
    console.log(responce); // <= calling mock function
    expect(spy).toHaveBeenCalledTimes(1);
  })
})

[b0tm1nd]

This should be a bug report I guess. Without this working the lib seems useless to me...
Exactly the same issue seems to be with jest.
Where with jest there is an additional workaround to use babel-plugin-rewire without altering any testing functions.
But can't get this plugin to work with vitest.

[codeBelt]

Also ran into this issue but it is mentioned in vitest Mocking Pitfalls docs.

https://vitest.dev/guide/mocking#mocking-pitfalls

[ks-keshava-rao]

will this ever be fixed by vitest ?

[sheremet-va]

No, there is nothing to fix, this is expected behavior

[ycfreeman]

i just ran into this exact same issue trying to migrate tests from jest to vitest

works in jest (at least kind of) and old code has a lot of module functions just like that

surely it is a bad practice but it is a major blocker for switching from jest to vitest 😢

[Siraj19176]

I am still running into this issue, is there any solution

[sheremet-va]

It is not possible: https://vitest.dev/guide/mocking.html#mocking-pitfalls

[robsimmons]

I don't see a good description of the behavior being described here in the mocking-pitfalls section; I'd be willing to PR a docs improvement but I'd like to make sure I understand the problem.

The following seems reasonable... at least I hope it is, because it's essentially the code I was drafting this morning to talk about different things mocking can do in my undergraduate software engineering course.

import { myFunc } from './software.ts';
import { libFunc } from './lib.ts';

describe('function under test', () => {
  it('should return 4', () => {
    expect(myFunc()).toBe(4);
  });
  
  it('should call libFunc(7) in the process of returning 4', () => {
    vi.mock('./lib.ts', { spy: true });
    expect(myFunc()).toBe(4);
    expect(libFunc).toHaveBeenCalledExactlyOnceWith(7);
  });

  it('should return 19 if libFunc returns false', () => {
    vi.mock('./lib.ts', () => {
      return {
        libFunc: vi.fn(() => false) 
      }
    });
    expect(myFunc()).toBe(17);
  });
});

but vitest hoists all the calls to vi.mock, which is a confusing problem here because it means that every test in a file must run in the same hoisted environment of mocked libraries, and tests 1 and 2 require a mocked library environment fundamentally incompatible with the library environment that test 3 expects.

Conceptually, this could, I would think, be fixed by hoisting and splitting files, in this case into three files, one for each test

/** File 2 **/
vi.mock('./lib.ts', { spy: true });

import { myFunc } from './software.ts';
import { libFunc } from './lib.ts';

describe('function under test', () => {
  it('should call libFunc(7) in the process of returning 4', () => {
        expect(myFunc()).toBe(4);
    expect(libFunc).toHaveBeenCalledExactlyOnceWith(7);
  });
});

/** File 3 **/
vi.mock('./lib.ts', () => {
  return {
    libFunc: vi.fn(() => false) 
  }
});

import { myFunc } from './software.ts';
import { libFunc } from './lib.ts';

describe('function under test', () => {
  it('should return 19 if libFunc returns false', () => {
    vi.mock('./lib.ts', () => {
      return {
        libFunc: vi.fn(() => false) 
      }
    });
    expect(myFunc()).toBe(17);
  });
});

so in my head I'm currently characterizing this as, I think not impossible, but very difficult and likely to cause other problems — such as beforeAll functions now getting run many more times than people expect, once for each hoisted-mock-environment. The fact that hoisting looks like a local action that triggers file-global actions does seem to greatly reduce its value, though I can certainly see it aiding modular testing when it's just being used for spying.

[panbhatt]

Hi Team, I recently faced this issue and tried to resolve this via using SINON but its of no rescue.
Eventually i change my function calls Eg. if Func A -> Calling B and C in the same file (js), then i prepended the call with THIS, it seems to be working.

[StaceyD22]

Hi all, ran into this issue. I found a clunky workaround:

import { renderHook } from '@testing-library/react';
import { expect, it, vi } from 'vitest';

describe('useKeycloak', () => {
  // If I wanted this to be an integration test, I wouldn't have to mock. But this in particular is a unit test. I don't want to
  // actually initialize Keycloak.
  it('returns expected values', async () => {
    vi.doMock('./AppKeycloakContext'); // I have a factory method for this in ./__mocks__/AppKeycloakContext.jsx
    const { useKeycloak } = await import('./AppKeycloak'); // AppKeycloak returns values from useContext(AppKeycloakContext)
    const keycloakContext = renderHook(() => useKeycloak());
    const { context, keycloak, initialized } = keycloakContext.result.current;
    expect(keycloak.token).toEqual('xyz');
    expect(keycloak.authenticated).toBeTruthy();
    expect(initialized).toBeTruthy();
    expect(context.headers.authorization.includes('xyz')).toBeTruthy();
  });

  // This test needs to use my actual AppKeycloakContext
  it('throws error when useKeycloak() called outside KeycloakProvider', async () => {
    vi.resetModules();
    vi.doUnmock('./AppKeycloakContext');
    const { useKeycloak } = await import('./AppKeycloak');
    expect(() => {
      renderHook(() => useKeycloak());
    }).toThrow(Error('useKeycloak() must be called within KeycloakProvider'));
  });
});

I really wanted this to work without all the dynamic imports but, alas, this was the only version I could get working.

You could extend this to use importOriginal and use some of the original contents of a module.

[ArianeBouchardConformit]

The simple workaround to this is to have your source file import itself.

For myFile.js:

import * as myFile from '@/utils/myFile.js';

export function functionA() {
  return myFile.functionB() * 2;
}

export function functionB() {
  return 10;
}

Then, in your test file, you'll be able to mock the function with a spy:

import * as myFile from '@/utils/myFile.js';

describe(`functionA`, () => {
  const FUNCTION_B_RESULT = 100;

  let functionBSpy;

  beforeEach(()=>{
    functionBSpy = vi.spyOn(myFile, 'functionB').mockReturnValue(FUNCTION_B_RESULT);
  })

  it(`SHOULD call functionB.`, () => {
    myFile.functionA();
    expect(functionBSpy).toHaveBeenCalledWith();
  })

  it(`SHOULD return the result of functionB, multiplied BY 2.`, () => {
    const actual = myFile.functionA();
    expect(actual).toStrictEqual(FUNCTION_B_RESULT * 2);
  })
})

Incidentally, this workaround works for Jest as well.

I absolutely disagree with the maintainers that "if you need to mock other functions in the same file, your code is bad". having a file grouping your string utils, for instance, where some of them call each other, absolutely makes sense. Sure, I COULD make it an object/class for no reason other than to please Vitest, but making a class that isn't meant to be instantiated is just weird. Or I COULD test the whole behaviour without mocking the inner function, but at this point, it's not an unit test, it's an integration test.

[misaelburboa]

It worked for me! Thank you dude

[rahulkarajgikar]

nice one!