JSZip generateAsync times out when run in jest - javascript

Very strange issue when I try to upgrade jest from v26 to v29.
A test executes
console.log("before fzip", JSZip.support.blob);
const fzip = await zip.generateAsync({ type: "blob" });
console.log("fzip", fzip);
If I run jest v26.6.x, it succeeds as long as I have jest-environment-jsdom v26.5.x in `package.json'
If I remove jest-environment-jsdom, the call fails (goes to catch):
error! TypeError: this._timerAPIs.setImmediate is not a function
at FakeTimers._fakeSetImmediate
If I upgrade jest and jest-environment-jsdom to v29.0.x, the call times out. I can see the first log message but not the second.
Any ideas are greatly appreciated!

Just in case someone is interested.
Apparently, JSZip.generateAsync calls setImmediate internally, so the following works:
import {setImmediate} from “timers”
…
global.setImmediate = setImmediate
(jest v27 was failing as it had an issue with setImmediate)

Related

Pending operations in playwright on nodejs

I'm trying to get a new page at the moment of clicking on the link:
await test.step(`Step name`, async () => {
const [newPage] = await Promise.all([
context.waitForEvent('page'),
page.click('//span[normalize-space(#title)=\'Bup\']')
]);
}
And I get this page. Further operations with this instance are successful. But after 30 seconds the test ends with the following error:
Timeout of 30000ms exceeded.
Pending operations:
- browserContext.waitForEvent at "path to the file":48:21
- at <unknown>
I will assume that it is related to a promise, but I do not understand what exactly the problem is. Help is needed.
Playwright v14.0, nodejs v16.7.0.
I run the tests with the following command: npx playwright test tests/diag.spec.mjs --headed
A strange observation. When I run it in debug mode, there is no such error
:
PWDEBUG=1 npx playwright test tests/diag.spec.mjs
Ok, I found the answer, but it's a little weird. You need to increase the timeout in the playwright config:
https://github.com/microsoft/playwright/issues/8268
Also you can add test.slow() https://playwright.dev/docs/api/class-test#test-slow

Javascript promise never resolves

I am using rotateByDegrees from a library called node-poweredup in a typescript project:
motor.rotateByDegrees(20,10).then(function(value) {console.log("test");}, function(value) {console.log("error");});
I would expect to see "test" after successful completion, but the promise never resolves. If I use await, it hangs on the await line forever.
Replicating the syntax that appears to be used in the rotateByDegrees function:
let promise = new Promise((resolve) => { return resolve(); });
does not compile, I get error TS2794: Expected 1 arguments, but got 0. Did you forget to include 'void' in your type argument to 'Promise'? I can make it compile and behave as expected with resolve(true), but how does it compile in the library then? Do I misunderstand promises? Some feature in typescript? A bug in the library? I am a newbie to JavaScript, I don't want to over-complicate this question by including irrelevant details. If you can give me hints on what I am missing and how to debug this, I can provide all relevant details.
Thanks to the helpful comments I was able to narrow it down to the compilation of the library. I did in fact not use a pre-compiled binary but had to compile the library myself using electron-rebuild to make the bluetooth adapter work. I did the following test:
git clone https://github.com/nathankellenicki/node-poweredup.git
cd node-poweredup
npm install
npm run build
this compiles without error. I created the following test file
const PoweredUP = require("node-poweredup");
const poweredUP = new PoweredUP.PoweredUP();
poweredUP.scan(); // Start scanning for hubs
console.log("Looking for Hubs...");
poweredUP.on("discover", async (hub) => { // Wait to discover hubs
await hub.connect(); // Connect to hub
console.log(`Connected to ${hub.name}!`);
const motorA = await hub.waitForDeviceAtPort("A"); // Make sure a motor is plugged into port A
motorA.rotateByDegrees(20,10).then(function(value) {console.log("test");});
});
and get the expected output:
node-poweredup$ node test.js
Looking for Hubs...
Connected to MyHub2!
test
Connected to MyHub3!
test
When I changed the first line to
const PoweredUP = require(".");
to make it use my self-compiled binary I get
node-poweredup$ node test.js
Looking for Hubs...
Connected to MyHub2!
Connected to MyHub3!
Of course this is only a partial answer because I still don't know why it compiles differently on my machine, but at least I have an idea where to start searching for the problem.

Jest Call retries were exceeded

I have error in the following below test. My node version is : v12.10.0. is there any alternative of setTimeout?
test('demo code', async () => {
const cc = await projectSetup(project);
const onNotification = jest.fn();
cc.sendNotification();
await waitForExpect(() => {
expect(onNotification).toHaveBeenCalledTimes(2);
});
});
The Error log is as
Call retries were exceeded
at ChildProcessWorker.initialize (../../../node_modules/jest-worker/build/workers/ChildProcessWorker.js:230:21)
just add jest.useFakeTimers(); after your imports
...
jest.useFakeTimers();
test('demo code', async () => {
const cc = await projectSetup(project);
const onNotification = jest.fn();
cc.sendNotification();
await waitForExpect(() => {
expect(onNotification).toHaveBeenCalledTimes(2);
});
});
it works in my code
In my case, the actual problem was with the promise handling.
I got the same issue when I was running all my test cases in one go with the jest.
Solution:
Try running one test separately then see what error is coming.
I got the below error after running one problematic test separately where earlier I was getting the Call retries were exceeded:
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "TypeError: Cannot read property 'code' of undefined".] {
code: 'ERR_UNHANDLED_REJECTION'
}
With this, I was sure that the problem is with the catch block and when I added it in the async service API function then the test case worked perfectly fine.
Maybe you can also try the same and see if it works for you or not.
I am using the below config:
node: 15.13.0
npm: 7.8.0
jest: 26.6.3
Try running npm doctor using the latest npm version. It's a great tool and it helped me diagnose permission and ownership issues right away.
Takeaway:
Verify File/Folder Permissions & Ownership
Encountered same error when updating the vue-jest version to below listed versions
#vue/vue3-jest: ^27.0.0-alpha.4
#vue/cli-plugin-unit-jest: ~5.0.0,
node: v17.9.0 or v16.14.2
Error disappeared, once downgraded it to node version v14.x.x
Hunch is - the latest node versions are not compatible with the dependencies.
I was able to run the test's successfully doing the following;
Install npm i -D jest-canvas-mock
Update the jest.config.ts file to have:
export default {
...
testEnvironment: "jsdom",
setupFiles: ["jest-canvas-mock"],
}

Possible Unhandled Promise Rejection (id: 0): Error: "getLoginData" is read-only

Destructuring from props is not working inside an async function while it's working fine if I use it using this.props.
This is for a react-native app already in production which suddenly started giving this error 2 days back.
I've tried upgrading babel using this
But no success so far.
If I use this.props.getLoginData instead, it works fine
If I use following function, it's erroneous:
yo = async () => { // with async
const { getLoginData } = this.props; // error
};
While the following function works fine:
yo = () => { // without async
const { getLoginData } = this.props;
console.log(getLoginData); // works fine
};
This also works fine:
yo = async () => { // with async
console.log(this.props.getLoginData); // works fine
};
I expect both of the scenarios to run fine.
Please clone and run this repo to reproduce this bug.
Please find the steps to run the project and environment info in README.md.
P.S.: You will find the error in console( Press ⌘⌥I )
It looks like a dependency of babel is the cause of the issue in my case.
When I look in my package-lock.json, and search for plugin-transform-regenerator I see version 7.4.5. Locking the version to 7.4.4 by adding it to my package.json allows me to build without issue.
This problem would have been easier to track down if I was not ignoring my package-lock.json.
In summary,
npm i -E #babel/plugin-transform-regenerator#7.4.4
I've encountered the same problem.
Using babel version 7.4.4 didn't help me, but I've found another solution that worked - wrapping the destructure in try-catch block.
I still don't know why this problem happens though - will update when I do.
________UPDATE_______
Eventually, the solution #makenova offered worked (Thanks man!).
What I had to do is to remove all node modules + package-lock, then run
npm i -E #babel/plugin-transform-regenerator#7.4.4
and after that run
npm i
Before that I've used yarn and it didn't do the trick.
Update:
nicolo-ribaudo fixed the issue here: https://github.com/facebook/regenerator/pull/377
An alternative solution is to force the regenerator-transform to use ~0.13.0 as suggested by nicolo-ribaudo.
If you are using yarn, add this to your package.json:
"resolutions": {
"regenerator-transform": "~0.13.0"
}
If you are using npm:
Install it as a devDependency
Delete package-lock.json
Re-install dependencies
I've a async function, when destructuring and save const show me error: Possible Unhandled Promise Rejection (id: 0): Error: “userOperations” is read-only , this worked for me (change let by const):
https://github.com/facebook/regenerator/issues/375#issuecomment-527209159

Mocha test not running the `try..finally` clause

I am running my Node.js tests with Mocha. When I add a try..finally clause I expect that Mocha will run the finally bit after the test. It works with errors and exceptions, but not when the test times out.
The tests below show the issue in detail.
describe('try-finally', () => {
it('should run finally with an error', async() => {
console.log('starting')
try {
console.log('started')
throw new Error('Error!')
console.log('finished')
} finally {
console.log('finally!')
}
});
it('should run finally with a timeout', async() => {
console.log('starting')
try {
console.log('started')
await timeout()
console.log('finished')
} finally {
console.log('finally!')
}
});
});
function timeout() {
return new Promise(ok => {
setTimeout(ok, 10*1000)
})
}
To run the test: save into a file try-finally.js, install Mocha with npm install -g mocha and then run test with mocha --exit try-finally.js. Output:
$ mocha --exit try-finally.js
try-finally
starting
started
finally!
1) should run finally with an error
starting
started
2) should run finally with a timeout
0 passing (2s)
2 failing
1) try-finally
should run finally with an error:
Error: Error!
at Context.it (try-finally.js:9:13)
2) try-finally
should run finally with a timeout:
Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. /home/alex/devo/batrasio/try-finally.js)
Both tests fail; the first one runs the finally clause and displays "finally!", while the second times out (waits for 10s when the test default timeout is 2s) and does not run the finally clause.
A couple of searches on Google and here on Stack Overflow yielded nothing. What am I doing wrong? Is this even possible, or do I need to use the obnoxious beforeEach() and afterEach() functions?
The finally block will run after the contents of the try block, not necessarily the whole test. Things like errors and exceptions are meant to be caught in the try block but with a timeout, the error is thrown by mocha (so outside of your try block).
If you need to run the finally block after the test is finished and it is taking too long, you can change the default timeout by putting
this.timeout(<insert time in ms>);
inside of your it function (or the describe function if you want it to apply to everything).
If you are wanting to do the same thing after every test, then yes the afterEach() function is the way to go.

Categories