Skip to content

fix: implement just-in-time test file list updates #1233

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

christianvuerings
Copy link

This change optimizes file system event handling by implementing a just-in-time approach to updating test file lists. Rather than immediately refreshing the test file list on every file system event, we now mark it as dirty and only update it when necessary (before running tests).

  • Add testFileListDirty flag to track when updates are needed
  • Only update test file list when running or debugging tests
  • Force update on initial startup for completeness
  • Significantly improves performance when renaming files in large repositories

fixes #1196

This change optimizes file system event handling by implementing a just-in-time
approach to updating test file lists. Rather than immediately refreshing the
test file list on every file system event, we now mark it as dirty and only
update it when necessary (before running tests).

- Add testFileListDirty flag to track when updates are needed
- Only update test file list when running or debugging tests
- Force update on initial startup for completeness
- Significantly improves performance when renaming files in large repositories

fixes jest-community#1196
Copy link
Collaborator

@connectdotz connectdotz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@christianvuerings, Thanks for the PR! A few questions before we dive into the code:

  1. Does updateTestFileList() not cause issues in your setup? We've heard from some users that it introduces noticeable delays at startup, which is why we added the "defer" runMode. I'm wondering if it might make sense to integrate this behavior into the defer mode instead? 🤔
  2. I see you've added dirty state checks for debug and runAllTests, good, but I didn't see a similar check for individual test item runs (in test-provider/test-item-data.ts). Also, having to add this check in multiple places feels a bit... less than ideal. 🤔
  3. Also, should we consider letting users know when updateTestFileList() is running—so they understand why running a seemingly small test could have noticeable delay due to this deferred action? That said, the notice has to be non-intrusive…
  4. I am also wondering how to we let user know the test file related stats (UI) are "dirty"? For example, in TestResultProvider.getTestSuiteStats(), and possibly other test-file-dependent info that we may need to test/review carefully for the impact of this new "dirty" state.

@coveralls
Copy link

Pull Request Test Coverage Report for Build 14434728301

Details

  • 14 of 15 (93.33%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.06%) to 98.129%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/JestExt/core.ts 10 11 90.91%
Totals Coverage Status
Change from base Build 14410704345: -0.06%
Covered Lines: 4123
Relevant Lines: 4130

💛 - Coveralls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] VSCode freezes on file change in large repo
3 participants