Estoy escribiendo una prueba y simulando una respuesta API de falla. La biblioteca que actúa como cliente para esa API genera un rechazo no detectado en este caso.

Esto es 100 % un error en la biblioteca y estamos en proceso de desaprobar esa biblioteca, pero migrar de ella tomará algunas semanas más y necesito que pase mi prueba hoy.

Desafortunadamente, Jest no ofrece una funcionalidad para deshabilitar este comportamiento. jest-circus agrega sus propios manejadores y falla la prueba. Esto sucede en jest-circus/src/globalErrorHandlers.ts .

Intenté comentar el cuerpo de no uncaught en ese archivo y eso realmente "soluciona" mi problema, lo que confirma que estos controladores son lo que estoy buscando.

 /** * Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. */ const uncaught = error => { // commenting-out this call to dispatchSync "fixes" the issue // (0, _state.dispatchSync)({ // error, // name: 'error' // }); };

Mi siguiente pensamiento fue hacer un process.removeAllListeners('unhandledRejection'); en mi prueba (en términos generales), pero eso no funciona, incluso cuando se ejecuta con --runInBand .

Después de un poco de depuración, descubrí que:

• process.pid en mi prueba y parentProcess.pid en jest-circus son iguales, pero
• process.listenerCount('unhandledRejection') y parentProcess.listenerCount('unhandledRejection') no son (cero y uno, respectivamente), y
• process.mainModule no está undefined en mi prueba, pero parentProcess.mainModule está definido en jest-circus (nombre de filename: .../jest/bin/jest.js ).

Eso me confundió por completo. Parecen ser procesos diferentes, pero comparten el mismo pid .

Para depurar aún más, hice un

 // in my test beforeAll(() => { process.emitWarning('emitted warning process from my test. count: ' + process.listenerCount('unhandledRejection')); }); // in globalErrorHandlers.js parentProcess.on('warning', warning => { console.log('parentProcess warning', parentProcess.listenerCount('unhandledRejection'), ' --- ', warning); });

Y esto genera parentProcess warning 1 --- Warning: emitted warning process from my test. count: 0 a la consola, lo que supongo que indicaría que son el mismo proceso (lo cual tiene sentido), ¡pero de alguna manera el listenerCount difiere!

Como nota al margen, los injectGlobalErrorHandlers de jest-circus siempre se ejecutan antes que mi código de prueba, incluso el código de espacio global. restoreGlobalErrorHandlers siempre se ejecuta después de .