我如何禁用开玩笑的未置换检测

发布于 2025-02-13 03:33:25 字数 2327 浏览 0 评论 0原文

我正在编写测试并模拟故障API响应。在这种情况下,充当该API的客户的库会产生未被拒绝的库。

这是图书馆中的100%错误,我们正在贬低该库,但是远离它的库将需要更多的几周,我今天需要测试通过。

不幸的是,开玩笑没有提供禁用此行为的功能。 Jest-Circus添加了自己的处理程序,并且未能通过测试。这发生在 jest-circus/src/globalrorhandlers.ts

我已经尝试在该文件中评论uck fused的主体,但确实确实“解决”了我的问题,这证实了这些处理程序是我想要的。

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

我的下一个想法是做一个process.removealllisteners('Unhandledseptiondements');在我的测试中(粗略地说),但即使使用运行-runinband 。

经过一番调试后,我发现:

  • process.pid在我的测试中,parentprocess.pid jest-circus中的是相等的,但是
  • process> process.listenercount('UnhandhandLeDledection ')parentprocess.listenercount('Unhandledseptiondeys')不是(分别为零和一个),并且
  • process.mainmodule我的测试中的 undefined ,但parentprocess.mainmodule在jest-circus中定义/BIN/JEST.JS )。

那完全使我感到困惑。它们似乎是不同的过程,但共享相同的pid

要进一步调试,我做了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);
  });

,此输出parentprocess警告1 ---警告:测试中发出警告过程。计数:0到控制台,我想这表明它们是相同的过程(这很有意义),但是lincerercount有所不同!

附带说明,Jest-Circus'InjectGlobalErrorhandlers始终在我的测试代码,甚至全局空间代码之前运行RETAREGLOBALERRORHANDLERS之后始终运行

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

恏ㄋ傷疤忘ㄋ疼 2025-02-20 03:33:25

似乎自定义的嘲笑环境可以解决问题:

// no-unhandled-rejection-failures-environment.ts

import NodeEnvironment from 'jest-environment-node';
import { AsyncEvent } from '@jest/types/build/Circus';

export default class MyEnvironment extends NodeEnvironment {
  async handleTestEvent(event, state) {
    if (event.name === 'test_start') {
      process.removeAllListeners('unhandledRejection')
    }
  }
}

// in the test file

/**
 * @jest-environment ./tests/no-unhandled-rejection-failures-environment.ts
 */

取自 >在GitHub问题上。

It seems a custom Jest environment will do the trick:

// no-unhandled-rejection-failures-environment.ts

import NodeEnvironment from 'jest-environment-node';
import { AsyncEvent } from '@jest/types/build/Circus';

export default class MyEnvironment extends NodeEnvironment {
  async handleTestEvent(event, state) {
    if (event.name === 'test_start') {
      process.removeAllListeners('unhandledRejection')
    }
  }
}

// in the test file

/**
 * @jest-environment ./tests/no-unhandled-rejection-failures-environment.ts
 */

Taken from this comment on a GitHub issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文