Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

228
Visualizações
How can I disable Jest's unhandledRejection detection

I'm writing a test and simulates a failure API response. The library that acts as a client for that API generates an uncaught rejection in this case.

This is 100% a bug in the library and we're on the process of deprecating that library, but migrating away from it will take some more weeks and I need my test passing today.

Unfortunately, Jest does not offer a functionality to disable this behavior. jest-circus adds its own handlers and fails the test. This happens in jest-circus/src/globalErrorHandlers.ts.

I've tried commenting-out the body of uncaught in that file and that does indeed "fix" my problem, which confirms these handlers are what I'm looking for.

/**
 * 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'
  // });
};

My next thought was to do a process.removeAllListeners('unhandledRejection'); in my test (roughly speaking), but that doesn't work, even when running with --runInBand.

After some debugging, I found out that:

  • process.pid in my test and parentProcess.pid in jest-circus are equal, but
  • process.listenerCount('unhandledRejection') and parentProcess.listenerCount('unhandledRejection') are not (zero and one, respectively), and
  • process.mainModule is undefined in my test but parentProcess.mainModule is defined in jest-circus (filename: .../jest/bin/jest.js).

That confused me completely. They seem to be different processes, yet share the same pid.

To debug further, I did a

  // 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);
  });

And this outputs parentProcess warning 1 --- Warning: emitted warning process from my test. count: 0 to the console, which I guess would indicate they are the same process (which makes sense), yet somehow the listenerCount differs!

As a side note, jest-circus' injectGlobalErrorHandlers always runs before my test code, even global-space code. restoreGlobalErrorHandlers always runs after.

about 4 years ago · Juan Pablo Isaza
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda