I have some really messy non-strict-compliant legacy code on javascript, running just fine on NodeJs 12, and I'm trying to abstract it away and test the overlaying, new layers of code using Jest/Mocks.
But when I try to run the tests I receive the following error:
Test suite failed to run
SyntaxError: /legacy-path/messy_legacy_code.js: Legacy octal literals are not allowed in strict mode (557:66)
at Parser._raise (node_modules/#babel/parser/src/parser/error.js:60:45)
I'm trying to mock it away first thing on my test code, but still get this error. It seems that Jest is trying to parse it with Babel; it really won't find any compliant code there... It just runs on Node, nothing else.
I already tried mocking the legacy code itself and also tried making a container to "abstract" it away and mocking the container. But it seems Jest still tries to read every bit of noncompliant code behind it.
My modern.test.js code looks like this:
jest.mock('../../../../legacy-path/messy-container')
const { ModernLayer } = require('../../../../modern-path/modern-module');
Any ideas on how I cant completely block Jest from trying to read this noncompliant code and just mock it away?
jest.mock('...') performs auto-mock, unless a mock from __mocks__ is used. It tries to process module exports and fails on syntax error.
The module should be manually mocked instead:
jest.mock('../../../../legacy-path/messy-container', () => ({ ModernLayer: ... }));
Related
I am trying to use jest with the esbuild based project. I tried to use esbuild-jest-transform and esbuild-jest transformers, but in both cases, I got error Cannot use plugins in synchronous API calls from esbuild. This makes sense and I tried to implement AsyncTransformer instead.
But after switching from SyncTransformer to AsyncTransformer, I got the following error:
● Invalid synchronous transformer module:
".../node_modules/esbuild-jest-transform/index.js" specified in the "transform" object of Jest configuration
must export a `process` function.
which implies that it should be implemented in the old way. Here are more details about it.
Could you please tell, me how to make jest to use AsyncTransformer instead of SyncTransformer?
I tried to use import() as is described in the doc, but got the same result.
i'm using strykerjs 5.6.0 with jest runner and react-testing-library. When I run the coverage with jest, all my test pass correctly, but when i run the mutation command (pointing to the same jest config file) i'm getting an error on initial test run because one test is getting a different value than the one i'm getting with the jest command in the coverage.
So, in thispicture it can be seen that the test is not getting the same value, this parseJSONString is a custom method to parse string type props to its js type (due to kill mutants i had to add this), its implementation is this, and it looks like the mutation is returning the fallback instead of the actual value of the array received in the coverage run.
The Stryker config is the following, any ideas? the jest version is the 26.6.3 also. I guess the issue must be related with the react testing library, but i do not understand what could be going on...
I could solve it using the waitFor hook, i don't know why, but stryker needs one render more than jest to get the test case properly mounted.
I have a TypeScript source file that has the following import:
// myCode.ts
import * as x from 'dep';
...
export class myClass {
...
}
where dep is a Node package that's included as part of the npm install. myCode.ts is a simple class that just has three methods. I would like to mock the entire myClass from inside a Jest test script that is written to test another class, myMainClass.
The problem I'm having is that the dep code is running some initialization that I can't seem to bypass. The initialization code fails outside the "real" environment so I simply want to bypass this for test purposes. No matter what I try I get an error that looks something like this:
Test suite failed to run
Dynamic Linking Error: ... error text ...
5 | // myCode.js
> 6 | import * as x from 'dep';
| ^
Again, the error is expected since I don't have these libraries locally (and don't want them for unit testing).
I was hoping I could add a simple mock statement (e.g., jest.mock('myClass'), or something similar, that would bypass anything to do with myClass. That way the code causing the link error would not be executed.
I'm fairly new to using Jest. Hopefully, this is a simple ask and I'm just missing the obvious. Thanks for the help.
Is there a way i can find out during runtime if a module is mocked via jest?
Since mocked modules get required normally and therefore the code gets executed (as seen here: jest module executed even when mocked
We need this because we have checks on top of each file to fail early when a mandatory environment variable is not set, which causes our tests to fail even if the module is mocked.
if (!process.env.SOME_ENV) {
throw new Error(`Mandatory environment variable 'SOME_ENV' not set`)
}
We are looking for something like this:
if (!process.env.SOME_ENV && utils.isNotMocked(this)) {
throw new Error(`Mandatory environment variable 'SOME_ENV' not set`)
}
where utils.isNotMocked(this) is the magic function which checks if the module is currently mocked.
As #jonrsharpe mentioned, it is typically not desirable that software can distinguish whether it is under test or not. This means, you will probably not find the feature you are hoping for in any mocking framework. Moreover, there may be more fundamental problems to provide such a feature, because you might have mixed test scenarios where for some test cases an object of the mocked class is used, and for other test cases an object of the original class is used.
Since you are using the early exit mechanism as a general pattern in your code, as you describe: What about creating a library function for this check - which then again can be doubled during testing such that in that case the function does not throw?
I trying to convert a nodejs project to TypeScript and while mostly I did not faced really difficult obstacles during this process, the codebase has few gotchas like this, mostly in startup code:
function prepareConfiguration() {
let cloudConfigLoader = require('../utils/cloud-config');
return cloudConfigLoader.ensureForFreshConfig().then(function() {
//do some stuff
});
}
I may be need just an advice on which approach for refactoring this has less code changes to be made to make it work in TypeScript fashion.
In response to comments, more details:
That require loads the node module, not a JSON file. From that module the ensureForFreshConfig function contacts with a cloud service to load a list of values to rebuild a configuration state object.
Problem is that mdule was made in standard node approach of "module is isngleton object" and its independencies include auth component that will be ready only when the shown require call is made. I know it is not best a way to do so..
Typesript does not allow "mport that module later" except with dynamyc import which is problematic as mentiond in comment.
The "good" approach is to refactor that part of startup and make the ensureForFreshConfig and its dependency to initiate its ntenras on demand via cnstructors.. I just hoped ofr some soluiton to reduce things to be remade durng this transition to the TypeScript
import { cloudConfigLoader } from '../utils/cloud-config'
async function prepareConfiguration() {
await cloudConfigLoader.ensureForFreshConfig()
// do some stuff
// return some-stuff
}
The function is to be used as follows.
await prepareConfiguration()