I just made a simple test:
npm i babel-cli babel-jest immutable jest-cli babel-preset-2015
And having simple test:
import {List} from 'immutable'
describe('it works',()=>{
it('should just work',()=>{
let li = List.of(1,3)
expect(li.size).toBe(2)
})
})
Very simple but test gives this:
- TypeError: Cannot read property 'size' of undefined
While List is defined and it is Function.
Do you have an Idea why this??
just need to add jest.unmock('immutable') on the first line.
According to docs:
By default, Jest automatically makes all calls to require() return a mocked version of the real module – so we need to tell Jest not to mock the file we want to test or else require('../fetchCurrentUser') will return a mock.
Related
I'm trying to mock the #hmscore/react-native-hms-location with jest. The function that one of my providers uses is HMSLocation.FusedLocation.Native.hasPermission(), but in one of my test I always get the following:
TypeError: Cannot read property 'Native' of undefined at call (C:\laragon\www\qmy-project\providers\LocationProvider.js:65:57)
I've tried to mock all the Library like this:
jest.mock('#hmscore/react-native-hms-location');
Even like this another way:
jest.mock('#hmscore/react-native-hms-location', () => {
const original = jest.requireActual('#hmscore/react-native-hms-location');
return original;
});
Always is the same. Any help please?
I'm trying to mock the fs module like so:
jest.mock('fs');
And as seen in this post - Mock fs function with jest
I should be able to treat the functions inside the module as jest.fn() and use - fs.existsSync.mockReturnValue(false); for instance.
That however does not seem to work and typescript gives me a bunch of errors.
All I want to do is assert a couple of functions like mkdirSync to have been called times or with some parameters and I seem to be running into this error -
'The "path" argument must be one of type string, Buffer, or URL. Received type undefined'
I tried to add fs.ts to the __mocks__ folder and mock it there - but that was no luck.
The file I am trying to test is a class and it imports fs. I am creating a new class instance in the beforeEach jest method.
So generally speaking, I don't really care to create a file or see if it exists, I wish to have a mocked return value or an implementation and just check with what parameters the fs module functions have been called.
It appears that running jest and mocking the file system in any way results in a conflict as jest is also using the fs module to handle the run.
The only solution i have found to overcome this issue:
export class SomeClass {
fs: typeof fs;
constructor() { this.fs = fs }
///code
}
Mock the fs methods like so in a test:
someClass.fs = {
mkdirSync: jest.fn()
} as any;
Assertion:
expect(someClass.fs.mkdirSync).toBeCalledWith('parameters');
I have a TypeScript file config.ts that will be run with node:
import myDependency = require('my-dependency');
export = {
doSomething = () => {
...
}
}
In other TypeScript file, I can import this file with full type safety:
import config = require('./config');
config.doSomething();
config.doSomethingElse(); // compiler error, this method doesn't exist
Now I want to unit test this script. In order to mock out the dependencies that this script require()s I'm using proxyquire, which lets me provide the values that my script will get when it makes calls to require(). Here's what my test might look like:
import proxyquire = require('proxyquire');
const config = proxyquire('./config', {
'my-dependency': {} // this mocked object will be provided when config.ts asks for `my-dependency`
});
expect(config.doSomething()).to.do.something();
This works fine, except that my config variable is of type any because I'm using proxyquire() in place of require(). TypeScript must give the require() function special treatment to allow it to perform module resolution. Is there a way to tell the TypeScript compiler that proxyquire() should also do module resolution, similar to require()?
I could rewrite config.ts as a class or make it use an interface. Then I would be able to explicitly type the variables in my tests by importing the class/interface definition. But allowing proxyquire() to implicitly type things for me would be far be the easier solution.
There is a workaround - you can get the type of config.ts module by importing actual module and using typeof in a type cast:
import proxyquire = require('proxyquire');
import configType = require('./config');
const config = <typeof configType> proxyquire('./config', {
'my-dependency': {} // this mocked object will be provided when config.ts asks for `my-dependency`
});
config.doSomething();
// config.noSuchMethod(); // does not compile
This is not ideal because you have to import the same module in your test twice - the real one just to get at the type of it and "proxiquired" one to actually use in your tests, and you have to be careful not to mix up the two. But it's pretty simple compared to the task of implementing another variant of module resolution for typescript. Also, when configType is used in this way - for typing only - its import will not even appear in generated javacsript code.
I've run into a problem with RequireJS that pops up randomly in different areas over and over, after a long period (about a year) of working fine.
I declare my requireJS file like this:
define(['TestController'], function (TestController)
{
return {
oneFunction: function(callback)
{
//When I try to use "TestController" here, I get the
//"Error: Module name "TestController" has not been
//loaded yet for context" error...
TestController.test(); //ERROR
//I had been using the above for years, without changes,
//and it worked great. then out of the blue started not
// working. Ok, let's try something else:
if(typeof TestController == "undefined")
{
var TestController = require('TestController'); //ERROR
}
//The above method worked for a few months, then broke AGAIN
// out of the blue, with the same error. My last resort is one
// that always works, however it makes my code have about 20+
//layers of callbacks:
require(['TestController'], function(TestController){
TestController.test();
//WORKS, but what's the point of declaring it as a
//requirement at the top if it doesn't work and I have to
//wrap my code every time? :(
});
},
anotherFunction: function()
{
console.log("hello");
}
}
});
I am getting the "Error: Module name "TestController" has not been loaded yet for context" error over and over until I re-declare the dependency... My question is, what's the point of declaring 'TestController' at the top as a dependency if I have to keep re-declaring it as if I never listed it? What am I doing wrong here?
I declare 'TestController' in other files and it works great, but every once and a while, ONE of the declarations will fail...and it's always a different file (there are about 200-300)... I never know which one, and the only way to fix it is to re-declare it and wrap it.
Anyone see anything I'm doing wrong that could be causing this? I keep updating RequireJS to see if it fixes it and it doesn't :/
Version
RequireJS 2.1.22
jquery-1.12.1
node 4.2.6
As #Louis pointed out, it was circular dependencies that was causing the problem.
Circular Dependency Solution #1: 'exports'
Here's the solution straight from RequireJS's documentation:
If you define a circular dependency ("a" needs "b" and "b" needs "a"), then in this case when "b"'s module function is called, it will get an undefined value for "a". "b" can fetch "a" later after modules have been defined by using the require() method (be sure to specify require as a dependency so the right context is used to look up "a"):
//Inside b.js:
define(["require", "a"],
function(require, a) {
//"a" in this case will be null if "a" also asked for "b",
//a circular dependency.
return function(title) {
return require("a").doSomething();
}
}
);
If you are familiar with CommonJS modules, you could instead use exports to create an empty object for the module that is available immediately for reference by other modules.
//Inside b.js:
define(function(require, exports, module) {
//If "a" has used exports, then we have a real
//object reference here. However, we cannot use
//any of "a"'s properties until after "b" returns a value.
var a = require("a");
exports.foo = function () {
return a.bar();
};
});
Circular Dependency Solution #2: Visualize with madge
I came accross this npm module that will create a dependency graph for you : https://github.com/pahen/madge
I've decided to analyze my code with madge and remove the circular dependencies.
Here is how I used the tool:
cd <Client-Code-Location>
madge --image dep.png .
This gave me an image of the dependencies, however there were no circular dependencies found. So I decided to try another way:
cd <Client-Code-Location>
madge --image dep.png --format amd .
This way I was able to see where I had the circular dependency. :)
i try to use the testing tool mocha in node. Consider the following test scenario
var requirejs = require('requirejs');
requirejs.config({
//Pass the top-level main.js/index.js require
//function to requirejs so that node modules
//are loaded relative to the top-level JS file.
nodeRequire: require
});
describe('Testing controller', function () {
it('Should be pass', function (done) {
(4).should.equal(4);
done();
});
it('Should avoid name king', function (done) {
requirejs(['../server/libs/validate_name'], function (validateName) {
var err_test, accountExists_test, notAllow_test, available_test;
validateName('anu', function (err, accountExists, notAllow, available) {
accountExists.should.not.be.true;
done();
});
});
});
});
as a testing result i have got:
$ make test
./node_modules/.bin/mocha \
--reporter list
. Testing controller Should be pass: 0ms
1) Testing controller Should avoid name anu
1 passing (560 ms)
1 failing
1) Testing controller Should avoid name anu:
Uncaught TypeError: Cannot read property 'should' of null
at d:\townspeech\test\test.spec.js:23:30
at d:\townspeech\server\libs\validate_name.js:31:20
at d:\townspeech\test\test.spec.js:22:13
at Object.context.execCb (d:\townspeech\node_modules\requirejs\bin\r.js:1869:33)
at Object.Module.check (d:\townspeech\node_modules\requirejs\bin\r.js:1105:51)
at Object.Module.enable (d:\townspeech\node_modules\requirejs\bin\r.js:1376:22)
at Object.Module.init (d:\townspeech\node_modules\requirejs\bin\r.js:1013:26)
at null._onTimeout (d:\townspeech\node_modules\requirejs\bin\r.js:1646:36)
at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
make: *** [test] Error 1
The first pass without any complication but the second, it seems like, that could not attach module shouldjs. Why?
I had the same problem. I solved it by using:
(err === null).should.be.true;
You can use should directly
should.not.exist(err);
That's a known problem with the should library: As it extends object, of course it only works when you have a concrete object. As null, by definition, means that you don't have an object, you can not call any methods on it or access any of its properties.
Hence, should is not available in this case.
Basically, you have two options of how to deal with this:
You could exchange actual and expected. This way, as long as you do not expect null, you have an object in the beginning and hence can access its should property. But, this is not nice, as it changes semantics, and does not work in all cases.
You could exchange the should library by another assertion library that does not have this problem.
Personally, I'd go with option 2, and my highly subjective personal favorite for this is node-assertthat (which has been written by me, hence it's my favorite).
Anyway, there are lots of other options, such as expect. Feel free to use any of these assertion libraries that best suits your style of writing tests.
One more option that I don't see mentioned here:
should(err === null).be.null
In you example that would would be:
should(accountExists).be.null
I always find expect works better with null and undefined as follows:
expect(err).be.null