Simplified unit/integration testing - mocking imports and global variables

[sobanieca]

It would be cool if Deno would support possibility to mock/stub imported es modules, as well as global variables like Deno etc. in unit/integration tests. My point is: I start coding some project, I don't focus on unit testing at all, as I don't know the final shape of the code, I want to iterate fast, etc. Once my project is in some meaningful shape, I end up with code like (pseudocode):

main.js

import log from "deno.land/std/log"
import parse from "deno.land/std/flags"

log.debug("starting my application");

const args = parse(Deno.args);

if(!args.mainParameter) {
  console.error("mainParameter missing!");
  Deno.exit(1);
}
...

I would love to, without having to modify this code, simply create test with option to override imports/global variables:

main.test.js

Deno.test("When running application without mainParameter should exit with code 1", {
  "deno.land/std/log": {
    debug: (msg) => console.log(`debug stub: ${msg}`)
  },
  "deno.land/std/flags": {
     parse: () => ({ mainParameter: null }) 
  },
  console: {
    error: () => {}
  },
  Deno: {
    exit: () => {}
  }
}, "path/to/main.js noMainParameter", (result) => {
 assert(result.exitCode, 1);
 assertSnapshot(result.stdout);
});

Such code would mimick deno run path/to/main.ts noMainParameter with all dependencies mocked. Result object would have all stdout and stderr in plain string format so I can assert against program output. Basically, I would love to be able to stub all not mine code without having to touch already written code base. I would also need result object to contain all helpers regarding output of my application, like stdout, network calls etc. This sounds quite challenging even to define, so I'm I would just like to start discussion. Nowadays, the way how I solve it is by introducing deps.js module which I import in my original code base (this means I need to refactor already working code) and then, I can override specific properties inside tests. It would be cool to avoid touching original code base, and build tests on-top of existing solution.

[codinronan]

I'm surprised nobody has engaged with this comment. The inability to use jest-style module mocking is baffling to me. I've already spent way more time trying to figure out how to do this very simple thing, than setting up a full testing flow in Node + jest would have taken.

And IF this functionality exists, then its documentation must be poor or non-existent because no search, ChatGPT, nor any other system has been able to find any reference to Deno's ability to do this. You mean the @std/testing/mock library? Yeah it doesn't mock an import by replacing it. If I want to do that, I have to use a custom import map and re-create the entire import surface of my project, which is quite large. All the library does is give me the tools to completely rebuild every library I import.

[woifes]

@marvinhagemeister is this feature planned?

[marvinhagemeister]

No, it's not planned at the moment as we're working on other areas of Deno at the moment. It's best to stay with jest or vitest if mocking is a requirement.

[woifes]

Today I fooled around with a small test project. Trying to get jest running with deno. Unfortunately I was not successfull. There is also no real guide I could find somewhere. Especially with module mocking which is digging itself very deeply into the module loading system of (normally) node I strongly doubt that this is even possible. And in the end if I migrate to deno I do it to have less work in setting up the tooling instead of even more. I still keep an eye on deno but is is still no alternative to me :(

[codinronan]

I was also not able to get Jest to run within Deno at all - the module comprehension is just too different. I appreciate the suggestion to stay with them, but it isn't possible so we are putting a migration strategy in place in our code to be able to use Deno's test runner

[woifes]

Hello @codinronan your migration strategy sounds interesting. Could you share some ideas from that? Mine would be that I lift all unit test which would require mocking of 3rd party components up to a integration test level. On the one hand it would ofc rise the test quality at one end but on the other hand I doubt that I will be able to achive the same "depth" in testing. And ofc the effort and footprint of the tests will also rise.

[sobanieca]

Thanks for bumping this! I come from .NET world where I always had to design my architecture in a way that allows to test the code in future (setup IoC containers etc.). This is huge overhead. When I start some new project I prefer much more to focus on "making it happen", iterate quickly and when final shape is ready I would like to focus on testing. Ability to pick up any file and test it thoroughly by mocking all global variables/imports would be an amazing feature and IMHO perfect selling point to convince people to start using Deno.

[codinronan]

I'm in much the same position, most of my JS career's testing has been based around the same idea you describe and I think it'd be a great set of features in Deno - it would also allow the popular testing libraries to write Deno ports, which would increase the size of the ecosystem.

For now I think I'm going to have to fallback to jest and simply replace my Deno-specific imports (mostly @std/lib stuff) on a case by case basis. Still more time than I'd like it to have taken, but a solution that will work for now.

Later edit: No way to get Jest to understand deno-style package management (you can get npm to install jsr, but can't get jest to use them). Will be falling back to deno and going with the "replace packages with mocks via import_map" approach.

[gmzacharydovel]

You're going to generally be better off if you can setup proper injection. The reason is the tests will have less to reset every time and can make a large different on platforms like Jest.

Having said that... the frontend world loves importing no-js modules to get a dynamically generated url path. I'm just not sure what the best way is to work around that on the frontend other than using jest or vitest.

[sobanieca]

Thanks. The whole point is to not have to setup proper injection. If runtime could offer me an option to take any part of code (could be scoped to file) and test it thoroughly without having to do any architectural changes - this is game changer IMHO.

[woifes]

I try to move to deno atm. I have a monorepo which I would like to move. But I stronlgy use import mocking for my tests. I was hoping that "scopes" might be a soltion in order to have a kind of override for the imports.
Unfortunately "scopes" are not allowed in single packages if you are in a monorepo.

[bgracie]

FWIW (just one developer) this is the main issue discouraging me from adopting Deno.  With the focus on security, simplicity, and types, I feel like the team is positioning Deno as a runtime that facilitates better engineering, and I really appreciate that. In my opinion, testing is a big part of better engineering in many settings, and I think import mocks are basically necessary to do any significant amount of JS testing. Also, one thing that LLM's are really good at is writing specs, so I think we are also seeing the cost/benefit of writing tests improve substantially. Many existing Node based projects also rely heavily on import mocking, and not having the feature available in Deno is going to block migration.

[wozniak-slawomir]

I second opinions above. It's giving me headaches trying to mock dependencies properly using Deno.

[nik-webdevelop]

Bumping up. Landed here after struggling with modules mocking.