Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Support Node.js fake timers

オープン
  • 何か問題がありますか？
#1,393 コメント 3 件 リアクション 2 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
javascript, node.js, react
領域
frontend, testing-qa

調査の方向性

まず、t.mock.timers.enable() と screen.findByText() を使用した Node.js の test runner の例を再現します。タイマーがモックされている場合に、findByText が非同期結果を待機する仕組みを追跡します。報告されている promise の解決失敗が解消されるか、サポートされる動作と回避策が明確に定義され、例のリグレッションテストが用意されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement
  • @testing-library/react version: 16.3.0
  • Testing Framework and version: node:test, 22.14.0
  • DOM Environment: jsdom 26.0.0
Relevant code or config:
import { screen } from '@testing-library/react';
import { it } from 'node:test';

await it('example', async (t) => {
   t.mock.timers.enable();  // Mocking timers using Node.js test runner
   await screen.findByText('some text');  // Attempting to find text
});
What you did:

In the code above, the timers are mocked using t.mock, which is provided by the Node.js test runner. The findByText query is used to search for specific text in the rendered output.

What happened:

When running this test, the following error message is displayed:

'Promise resolution is still pending but the event loop has already resolved'

This occurs because findByText internally uses setTimeout or setInterval (i.e., timers) to wait for the text to appear, and these timers are being mocked using t.mock.timers.enable(). As a result, the timer-based mechanism in findByText does not work correctly, causing the test to fail prematurely with the error message mentioned above.

Reproduction:
  1. Mock timers using t.mock.timers.enable() in the Node.js test runner.
  2. Attempt to find text asynchronously using screen.findByText().
  3. The error will occur when the test tries to resolve the promise.
Problem description:

The core issue is that findByText relies on timers internally to wait for the element to appear, but when these timers are mocked (using t.mock.timers.enable()), the expected behavior of waiting for the element to render is disrupted. This leads to the error:

'Promise resolution is still pending but the event loop has already resolved'

This behavior makes it difficult to use findByText in tests where timers are mocked or disabled. This can cause confusion and make it harder to test components that rely on async behavior.

Suggested solution:

One possible solution would be to handle cases where timers are mocked explicitly within the findByText query, by either:

  1. Detecting whether timers are mocked and adapting the logic accordingly, or
  2. Providing a way to configure findByText to explicitly use a custom timer (so the user can provide an unmocked version) or use a different timing mechanism (e.g., using async/await without relying on setTimeout).

Alternatively, allowing the user to opt-out of using timers in certain test scenarios (such as when mocking them) would be helpful.

Another workaround could be to manually wait for the element to appear without relying on findByText, using custom logic that doesn’t involve setTimeout or other mocked timers.

主要言語
JavaScript
スター
19.7k
フォーク
1.2k
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

testing-library/react-testing-library のほかの issue

testing-library/react-testing-library の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。