I have the class FooStorage that has an Array of Foo objects as a member variable. When testing FooStorage I want to mock the class Foo.
As described at ES6 Class Mocks, an automatic mock is all I need in my case. But when I try to mock the class, it doesn't seem to succeed. Instead when I try to reset the mock with mockClear(), I recieve an error message.
Below is the code and the output from jest:
foo.js
class Foo {};
export default Foo;
foostorage.js
import Foo from "./foo.js";
class FooStorage {
constructor() {
this.storage = []; // Array of Foo objects
}
}
export default FooStorage;
foostorage.test.js
import Foo from "../src/foo.js";
import FooStorage from "../src/foostorage.js";
import { jest } from "#jest/globals";
jest.mock("../src/foo.js");
beforeEach(() => {
Foo.mockClear();
});
test("if the Foo constructor hasn`t been called", () => {
const storage = new FooStorage();
expect(Foo).not.toHaveBeenCalled();
});
output
if the Foo constructor hasn`t been called
TypeError: Foo.mockClear is not a function
7 |
8 | beforeEach(() => {
> 9 | Foo.mockClear();
| ^
10 | });
11 |
12 | test("if the Foo constructor hasn`t been called", () => {
at Object.<anonymous> (test/foostorage.test.js:9:6)
I have already tried to put jest.mock("../src/foo.js"); before import Foo from "../src/foo.js"; but the problem wasn't solved.
Edit:
I am using Jest v. 27.0.6 with jest-environment-node v. 27.0.6 and #types/jest v. 27.0.1.
I also use the nodejs arguments --experimental-modules and --experimental-vm-modules so that I can use ES6 imports. I don`t use Babel or anything else. Just plain JavaScript.
Automatic mocking is supposed to work like the documentation explains. If it doesn't and results in said error, this means that the module wasn't mocked, so it would fail with manual mock as well. This can happen because a mock wasn't performed correctly (different case or extension in module path), or jest.mock hoisting didn't work (most commonly because of misconfigured Babel transform).
The way this code differs from what's shown in the documentation is that jest global is commonly used, while here it is imported value, so it's not the same as using jest global. This is obvious and known reason for hoisting to work differently.
It can possibly be fixed by ordering dependencies in a way that doesn't interfere with expected execution order:
import { jest } from "#jest/globals";
jest.mock("../src/foo.js");
import Foo from "../src/foo.js";
...
The hoisting of jest.mock relies on undocumented, spec-incompliant hack that also depends on Jest version and a specific setup. It's not guaranteed to work because ES imports are expected to hoisted above other statements by specs, and there are no exclusions.
A dated but stable workaround is to switch to require that are regular JavaScript function calls and are evaluated as is:
let { jest } = require ("#jest/globals");
jest.mock("../src/foo.js");
let { default: Foo } = require("../src/foo.js");
...
And an efficient solution is to get rid of jest import and set up a generic Jest environment with respective globals, so jest.mock could be hoisted as expected regardless of Jest version and other circumstances.
Related
I'm trying to do some very basic webcoponnets testing using typescript and mocha. I'm using jsdom to mock out the basic documents global, so I have --require jsdom-global/register in my moch opts.
Here is my test:
import { assert } from "chai";
class WordCount extends HTMLParagraphElement {
constructor() {
super();
}
}
describe("simple test", () => {
it("works", () => {
customElements.define('word-count', WordCount, { extends: 'p' });
assert.isOk(true);
});
});
But I get the following error:
ReferenceError: customElements is not defined
The latest version of JSDom (which I'm using) supports customElements. I think the issue boils down to window.customElements vs customElements. The former syntax works, but the code I'm trying to test uses the latter syntax. What's the difference?
In the browser context, there's not difference between window.customElements and customElements because window is the default namespace for the variables defined globally.
var my_var = 'foo"
console.log( window.my_var ) //foo
console.log( window.customElement === customElement )
The test JSDoc library is executed in the Node.js context, which is not a browser and therefore won't expose window as its global / default namespace.
However JSDoc exposes a simulated browser context through a window property. So you can use window.customElements() and there's no difference with the code you trying to test.
Is it possible to pass options to ES6 imports?
How do you translate this:
var x = require('module')(someoptions);
to ES6?
There is no way to do this with a single import statement, it does not allow for invocations.
So you wouldn't call it directly, but you can basically do just the same what commonjs does with default exports:
// module.js
export default function(options) {
return {
// actual module
}
}
// main.js
import m from 'module';
var x = m(someoptions);
Alternatively, if you use a module loader that supports monadic promises, you might be able to do something like
System.import('module').ap(someoptions).then(function(x) {
…
});
With the new import operator it might become
const promise = import('module').then(m => m(someoptions));
or
const x = (await import('module'))(someoptions)
however you probably don't want a dynamic import but a static one.
Concept
Here's my solution using ES6
Very much inline with #Bergi's response, this is the "template" I use when creating imports that need parameters passed for class declarations. This is used on an isomorphic framework I'm writing, so will work with a transpiler in the browser and in node.js (I use Babel with Webpack):
./MyClass.js
export default (Param1, Param2) => class MyClass {
constructor(){
console.log( Param1 );
}
}
./main.js
import MyClassFactory from './MyClass.js';
let MyClass = MyClassFactory('foo', 'bar');
let myInstance = new MyClass();
The above will output foo in a console
EDIT
Real World Example
For a real world example, I'm using this to pass in a namespace for accessing other classes and instances within a framework. Because we're simply creating a function and passing the object in as an argument, we can use it with our class declaration likeso:
export default (UIFramework) => class MyView extends UIFramework.Type.View {
getModels() {
// ...
UIFramework.Models.getModelsForView( this._models );
// ...
}
}
The importation is a bit more complicated and automagical in my case given that it's an entire framework, but essentially this is what is happening:
// ...
getView( viewName ){
//...
const ViewFactory = require(viewFileLoc);
const View = ViewFactory(this);
return new View();
}
// ...
I hope this helps!
Building on #Bergi's answer to use the debug module using es6 would be the following
// original
var debug = require('debug')('http');
// ES6
import * as Debug from 'debug';
const debug = Debug('http');
// Use in your code as normal
debug('Hello World!');
I've landed on this thread looking up for somewhat similar and would like to propose a sort of solution, at least for some cases (but see Remark below).
Use case
I have a module, that is running some instantiation logic immediately upon loading. I do not like to call this init logic outside the module (which is the same as call new SomeClass(p1, p2) or new ((p1, p2) => class SomeClass { ... p1 ... p2 ... }) and alike).
I do like that this init logic will run once, kind of a singular instantiation flow, but once per some specific parametrized context.
Example
service.js has at its very basic scope:
let context = null; // meanwhile i'm just leaving this as is
console.log('initialized in context ' + (context ? context : 'root'));
Module A does:
import * as S from 'service.js'; // console has now "initialized in context root"
Module B does:
import * as S from 'service.js'; // console stays unchanged! module's script runs only once
So far so good: service is available for both modules but was initialized only once.
Problem
How to make it run as another instance and init itself once again in another context, say in Module C?
Solution?
This is what I'm thinking about: use query parameters. In the service we'd add the following:
let context = new URL(import.meta.url).searchParams.get('context');
Module C would do:
import * as S from 'service.js?context=special';
the module will be re-imported, it's basic init logic will run and we'll see in the console:
initialized in context special
Remark: I'd myself advise to NOT practice this approach much, but leave it as the last resort. Why? Module imported more than once is more of an exception than a rule, so it is somewhat unexpected behavior and as such may confuse a consumers or even break it's own 'singleton' paradigms, if any.
I believe you can use es6 module loaders.
http://babeljs.io/docs/learn-es6/
System.import("lib/math").then(function(m) {
m(youroptionshere);
});
You just need to add these 2 lines.
import xModule from 'module';
const x = xModule('someOptions');
Here's my take on this question using the debug module as an example;
On this module's npm page, you have this:
var debug = require('debug')('http')
In the line above, a string is passed to the module that is imported, to construct. Here's how you would do same in ES6
import { debug as Debug } from 'debug'
const debug = Debug('http');
Hope this helps someone out there.
I ran into an analogous syntax issue when trying to convert some CJS (require()) code to ESM (import) - here's what worked when I needed to import Redis:
CJS
const RedisStore = require('connect-redis')(session);
ESM Equivalent
import connectRedis from 'connect-redis';
const RedisStore = connectRedis(session);
You can pass parameters in the module specifier directly:
import * as Lib from "./lib?foo=bar";
cf: https://flaming.codes/en/posts/es6-import-with-parameters
I try to test some basic redux reducers with jest and stumbled about a problem I can't solve on my own:
In my reducer I'm referencing a global method "__" (some i18n stuff), which implementation basically looks like the following:
window.__ = function(foo) { return window.i18n[foo]; }
The mentioned method is referenced in another module I include in my reducer via import definitions from 'definitions';
The definitions file looks like the following:
/* global __ */
// some basic stuff
export default () {
return __('foobar');
}
How is it possible to mock the __ method within the test code? Given that __ is not a module it can't be automocked. :/
You can use the following syntax to mock the global __ method:
global.__ = function(foo) { return foo; };
Is it possible to pass options to ES6 imports?
How do you translate this:
var x = require('module')(someoptions);
to ES6?
There is no way to do this with a single import statement, it does not allow for invocations.
So you wouldn't call it directly, but you can basically do just the same what commonjs does with default exports:
// module.js
export default function(options) {
return {
// actual module
}
}
// main.js
import m from 'module';
var x = m(someoptions);
Alternatively, if you use a module loader that supports monadic promises, you might be able to do something like
System.import('module').ap(someoptions).then(function(x) {
…
});
With the new import operator it might become
const promise = import('module').then(m => m(someoptions));
or
const x = (await import('module'))(someoptions)
however you probably don't want a dynamic import but a static one.
Concept
Here's my solution using ES6
Very much inline with #Bergi's response, this is the "template" I use when creating imports that need parameters passed for class declarations. This is used on an isomorphic framework I'm writing, so will work with a transpiler in the browser and in node.js (I use Babel with Webpack):
./MyClass.js
export default (Param1, Param2) => class MyClass {
constructor(){
console.log( Param1 );
}
}
./main.js
import MyClassFactory from './MyClass.js';
let MyClass = MyClassFactory('foo', 'bar');
let myInstance = new MyClass();
The above will output foo in a console
EDIT
Real World Example
For a real world example, I'm using this to pass in a namespace for accessing other classes and instances within a framework. Because we're simply creating a function and passing the object in as an argument, we can use it with our class declaration likeso:
export default (UIFramework) => class MyView extends UIFramework.Type.View {
getModels() {
// ...
UIFramework.Models.getModelsForView( this._models );
// ...
}
}
The importation is a bit more complicated and automagical in my case given that it's an entire framework, but essentially this is what is happening:
// ...
getView( viewName ){
//...
const ViewFactory = require(viewFileLoc);
const View = ViewFactory(this);
return new View();
}
// ...
I hope this helps!
Building on #Bergi's answer to use the debug module using es6 would be the following
// original
var debug = require('debug')('http');
// ES6
import * as Debug from 'debug';
const debug = Debug('http');
// Use in your code as normal
debug('Hello World!');
I've landed on this thread looking up for somewhat similar and would like to propose a sort of solution, at least for some cases (but see Remark below).
Use case
I have a module, that is running some instantiation logic immediately upon loading. I do not like to call this init logic outside the module (which is the same as call new SomeClass(p1, p2) or new ((p1, p2) => class SomeClass { ... p1 ... p2 ... }) and alike).
I do like that this init logic will run once, kind of a singular instantiation flow, but once per some specific parametrized context.
Example
service.js has at its very basic scope:
let context = null; // meanwhile i'm just leaving this as is
console.log('initialized in context ' + (context ? context : 'root'));
Module A does:
import * as S from 'service.js'; // console has now "initialized in context root"
Module B does:
import * as S from 'service.js'; // console stays unchanged! module's script runs only once
So far so good: service is available for both modules but was initialized only once.
Problem
How to make it run as another instance and init itself once again in another context, say in Module C?
Solution?
This is what I'm thinking about: use query parameters. In the service we'd add the following:
let context = new URL(import.meta.url).searchParams.get('context');
Module C would do:
import * as S from 'service.js?context=special';
the module will be re-imported, it's basic init logic will run and we'll see in the console:
initialized in context special
Remark: I'd myself advise to NOT practice this approach much, but leave it as the last resort. Why? Module imported more than once is more of an exception than a rule, so it is somewhat unexpected behavior and as such may confuse a consumers or even break it's own 'singleton' paradigms, if any.
I believe you can use es6 module loaders.
http://babeljs.io/docs/learn-es6/
System.import("lib/math").then(function(m) {
m(youroptionshere);
});
You just need to add these 2 lines.
import xModule from 'module';
const x = xModule('someOptions');
Here's my take on this question using the debug module as an example;
On this module's npm page, you have this:
var debug = require('debug')('http')
In the line above, a string is passed to the module that is imported, to construct. Here's how you would do same in ES6
import { debug as Debug } from 'debug'
const debug = Debug('http');
Hope this helps someone out there.
I ran into an analogous syntax issue when trying to convert some CJS (require()) code to ESM (import) - here's what worked when I needed to import Redis:
CJS
const RedisStore = require('connect-redis')(session);
ESM Equivalent
import connectRedis from 'connect-redis';
const RedisStore = connectRedis(session);
You can pass parameters in the module specifier directly:
import * as Lib from "./lib?foo=bar";
cf: https://flaming.codes/en/posts/es6-import-with-parameters
I have the following scenario:
In my .js file I import the default export of a package foo
This export has two properties Bar and Baz, they are both ES6 classes
In my .test.js file I now want to mock these two classes and spy on their constructors
The .js code looks roughly like this:
import foo from 'foo/dist/foo.min';
const { Bar, Baz } = foo;
...
const fooBar = new Bar();
In my .test.js file I now mock the package like this:
jest.mock('foo/dist/foo.min');
The automatic mock works as expected, but of course does not allow me to spy on the constructors of Bar and Baz which is what I would want.
I have tried to simply do this in my .test.js file:
import foo from 'foo/dist/foo.min';
jest.mock('foo/dist/foo.min');
foo.Bar = jest.fn();
foo.Baz = jest.fn();
But this does not seem to do anything, my fake jest.fn() constructors never get called.
I have read this page in the docs: https://jestjs.io/docs/en/es6-class-mocks.html but it seems to assume the the ES6 class to be mocked is being exported directly from a module, and is inside the project and not an npm package.
Automatic mock does not work for me because the classes are not exported themselves.
I can't use mockImplementation() on my foo package, since it is not a function, right?
I don't see a way to do a manual mock because it is a npm package.
I'd appreciate any suggestions on how to solve this.
A few notes:
babel-jest hoists calls to jest.mock so they happen first.
The automatic mock created by Jest reflects the structure of the module.
So calling jest.mock('foo/dist/foo.min'); means that Jest will auto-mock that module for any code that runs during that test, and the auto-mock will reflect the structure of the original module.
It looks like your code calls the Bar constructor as soon as it runs.
This means the following test should work:
import foo from 'foo/dist/foo.min'; // foo is already auto-mocked...
import './code'; // import your code (which calls the Bar constructor)
jest.mock('foo/dist/foo.min'); // ...because this runs first
test('constructor was called', () => {
expect(foo.Bar).toHaveBeenCalled(); // SUCCESS
})
It looks like your test didn't work because you set foo.Bar = jest.fn(); after your code had run (overwriting the earlier spy that did get called when your code ran).