Mocking with jest doesn't work

[bennyk8y]

Hi, this is jest.config.template.js:

module.exports = {
  testEnvironment: 'node',
  testMatch: ['**/*.test.ts', '**/**/**/*.test.ts', '**/**/**/*.spec.ts'],
  transform: {
    '^.+\\.ts?$': [
      '@swc-node/jest',
      {
        sourcemap: true,
        experimentalDecorators: true,
        emitDecoratorMetadata: true,
        keepClassNames: true,
      },
    ],
  },
};

this is the test file:

import { getBankTransactionOrFail } from '../../models/queries/getBankTransaction';

jest.mock('../../models/queries/getBankTransaction');

describe('fetchRelatedTransactionsForClassification', () => {

  it('no related entities', async () => {
    (getBankTransactionOrFail as jest.Mock).mockResolvedValueOnce(makeBankTransaction());
    expect(1).toBe(1);
});

result an error of TypeError: _getBankTransaction.getBankTransactionOrFail.mockResolvedValueOnce is not a function.

using ts-jest preset works as expected

versions:
"@swc-node/jest": "1.6.5",
"jest": "28.1.3"

[rosmcmahon]

similar issues with Sinon stub/spy:
TypeError: Descriptor for property myFunctionName is non-configurable and non-writable

[meskill]

The issue is related to #700

In previous major version @swc-node/[email protected] mocks are working right

I'm expecting that #714 will fix the problem

[meskill]

Please, check the latest version

[rosmcmahon]

no change for Sinon

[fatso83]

@rosmcmahon I wrote up a small answer on SO on how you can generally use Sinon alongside Quibble (or any other similar tool, like Proxyquire) to mock modules when running SWC. Assumes your target module type is "commonjs".

[rosmcmahon]

yeah, catching up on this again. basically sinon recognising that swc is building the module exports in a more correct way, but that it's out of scope for their project to support this.

[fatso83]

The problem is that Jest is a combination of many things:

• test runner (a la Mocha)
• stubs and spies (a la Sinon)
• module interception (a la Proxyquire)

By itself, nether Jest nor Sinon can know that an object is a module with exports and what you want to do with it 🤷 Both require the user to know what they are looking at.

[rosmcmahon]

thanks @fatso83, sorry for the delay.
yeah, i was adding swc to an older codebase of mine. the solution was to remove swc, and revert to transpileOnly with type-checking step.
IMO if i'm using proxyquire then i'm doing something wrong as i should write my code with testing in mind. i even avoid stubs these days

[fatso83]

In the article I have out for review I discuss three different approaches to exactly this issue, one of which is the tool independent route of exposing ways of injecting dependencies. I guess you are doing something similar to what I propose there?

Would really like some extra set of eyes on this, so if you could spare five minutes I can perhaps help quite a few people in avoiding the trouble you experienced 🙏