Define a proper way to mock imports

[alexey-yarmosh]

Currently we are unable to mock our own modules and npm modules. That is so because we are using ES modules and seems that there are no out-of-the-box solution for the TS+ES modules combination. For that reason we are not able to unit test some of our modules.

At the end we should come to the solution that will be able to mock imports both of our own and npm dependencies of any kind. Without cheats like DI, mutation of the existing object, or things like export default {func1, func2, func3}.

Possible options:

• https://www.npmjs.com/package/testdouble (testdouble should we specified as loader where currently sits tsx)
• https://github.com/iambumblehead/esmock (esmock should we specified as loader where currently sits tsx)
• use esm loader (Document how to configure Node to allow stubbing EcmaScript modules sinonjs/sinon#1832)
• maybe some other frameworks solves that (Jest, etc.)

[patrykcieszkowski]

default exports is probably the right way to do it. I'm struggling with similar issue myself on another project, I'll be happy to hear what you come up with.

btw, object mutation isn't cheating - at least not in this context. That's essentially what sinon does underneath the hood. The problem is, sinon relies on this mechanism, and ES selective imports bypasses it, making it impossible to hook into it.

[alexey-yarmosh]

I've tested solutions in sandbox (code):

• both "testdouble" and "esmock" work and suit us. Only thing is that they both work with "ts-node" as a loader (we are using "tsx"). Changing the loader should not take a lot of time.
• "jest" work and suit us too. Choosing it will mean replacing mocha+sinon+chai+testdouble with jest, which is nice, but requires more time.
• sinon+esm loader didn't work out, so that option is discarded.

Personally I'd prefer "jest". There are not so many tests right now, but there are plans to write a lot of them (jsdelivr/globalping-probe#101). So having a framework instead of a list of libraries will help us to write them faster. We can try to migrate a few most hard test suits to see how much effort that requires.

@MartinKolarik @patrykcieszkowski maybe you have any thoughts?

[patrykcieszkowski]

I personally like the setup built with swappable libraries, over having to rely on a framework.

As for the custom loader - we've switched to tsx solely because its quicker, as it bypasses the TS validation - making tests slightly less annoying to develop. Nothing else, so I wouldn't worry too much about it personally.

Correct me if I'm wrong, but I don't think neither testdouble or esmock support spying on functions, so keeping sinon for call tracking will still be useful.

[MartinKolarik]

I'm not strongly against jest but also not particularly in favor. The combination of libraries we already have (+ the es mocking) has roughly the same features, and we use it consistently across all projects. As for the loader, we can definitely change it (see #180).

[alexey-yarmosh]

I've tested ts-node with transpileOnly option + testdouble in our environment and it seems to work fine. Execution time is still around 5 secs. Also in sandbox with same environment I was able to configure wallaby.js and test debugger. So I think there are no more blockers to use mocha+sinon+chai+testdouble. I'll prepare the migration PR soon and update old mocking to testdouble mocking.

[jimaek]

@alexey-yarmosh Can this be closed?

[alexey-yarmosh]

Yes.