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.

[marvinhagemeister]

There is currently no way to mock globals or modules in Deno's own test runner. If your tests rely on that feature then you're better served with jest or vitest for the time being.

[codinronan]

@marvinhagemeister thank you for confirming, that helps us plan. Appreciate it!

[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.