-
-
Notifications
You must be signed in to change notification settings - Fork 11
Open
Description
Rstest is currently under active development, and we plan to release a preview version with most of the basic features for testing by June 2025, and support more advanced features and further features in subsequent iterations. The first stable version will be released in late 2025.
Rstest features track
Basic Features
- Expect API (Jest Compatible)Lifecycle hooks (beforeAll、beforeEach、afterAll, etc.)Setup filesSnapshot testing (Jest Compatible)Source mapTest API (describe、test、only、each, etc.)In-source testingDefault ReporterOut-of-the-box TypeScript / JSX supportCLI
- rstest run
- rstest watch
- rstest list
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.Spy & Rstest utility (rstest.spyOn
、rstest.fn
, etc.)Mocking- mock
- doMock
- unmock
- importMock
- importActual
- resetModules
- hoist
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.Auto MockConfig- Test configuration support, such as
include
,pool
,setupFiles
, etc. - Build configuration support, such as
resolve
,transform
,external
, etc (based on rsbuild).
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.API Documentation 🚧Pool & isolated- forks
- vmForks
- threads
- vmThreads
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.Environment- node
- jsdom
- happy-dom
- custom environment
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.ESM support 🚧Watch mode 🚧CLI shortcutsCoverage- v8
- istanbul
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.Integration- Out-of-the-box Rsbuild testing support
- Out-of-the-box Rslib testing support
- Out-of-the-box Rspack testing support
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Advanced Features
- WorkspaceOut-of-the-box Lynx testing supportRsdoctor integrationMore builtin reporters & Stablize Reporter API
- HTML Reporter
- JSON Reporter
- GitHub Actions Reporter
- Summary Reporter
- JUnit Reporter
- Custom Reporter
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.Rstest UI (Provide UI to view and interact with tests)VS Code extensionTest Sharding & merge reportsSupport filter tests via related source filesTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Further Features
- Browser ModeBenchmark testingType testingAI ExplorationTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Timeless0911, chenjiahan, zoolsher, njzydark, scttcper and 43 moreDominusKelvin, denniscual, notimmates, abenhamdine, mmichels-brex and 17 more7rulnik, mmichels-brex, FredrikAugust, xcfox, pjean-dev and 6 more
Activity
Ghostblad3 commentedon Jun 27, 2025
Hello there. One of the biggest issues of Jest is that it reads all the necessary modules for each test but does not cache them during runtime.
In front-end development most of these modules are the same. So you end up reading for each test thousands of files again and again.
A simple React component without 3rd party libs, need around 800 module files. However a React component that imports a component library, and icon library, a state management library etc can easily peak at more than 5k module files during tests because a lot of these 3rd party libraries are barreled. Now imagine you if you got 200 different React components where each needs about 5k files and you want to run all the tests you need to hit the disk 200 * 5_000 = 1_000_000 times.
On a decent personal laptop that's not really a problem.
However in a restricted enterprise environment where you have a cheap enterprise U series low powered laptop and you are forced to use windows with limited permissions, have bit-locker enabled which degrades SSD performance, security software monitoring the background and an aggressive windows defender that thinks that the node process is a ransomware because it reads thousands of files really fast it gets unbearable. Note that even requesting access for WSL can be denied since you aren't messing with docker and microsevices if your role is front-end dev only and having a folder scan exclusion and node process scan exclusion from the windows defender is a big no from the IT security guys for security reasons (I don't disagree with the window defender part).
I started experimenting with modifying Jest source code and added high precision timers in the function that did readFileSync from the disk. I observed that reading for example 5k node module files alone could take 135 secs which is insane to me and can lead to execution times of 3 minutes for a single test file since jest loads reads other files from the file system before that like jsdom related files, package json files and also it needs to spin up an isolated VM for running the test etc.
My proposal is to cache and share the node modules during runtime. This can avoid I/O bottleneck especially in the type of environment I described above.
My second proposal is a bit crazy but it can dramatically improve performance in I/O starved environments.
Create a disk based module pool. Instead of reading a module file at a time, add it after the tests finish to a file pool in the disk.
module-pool.json
The last_modified contains the last time the file was modified in the file system.
The last_accessed contains the last time a test needed the specific module.
The last_modified can help us invalidate the content of the file if it was updated and the last_accessed can help us determine if the file has to be requested for a long time (user could provide an option to discard modules from the pool if they haven't been used for example 2 months during the test runs).
Since CI/CD can be tricky to determine last_modified (node_modules dependencies are reinstalled on each CI/CD unless you can retain somehow the old modules after each pipeline execution, I am not sure if it is worth it and what kind of ) this second proposal could be under a config value like "localDevelopmentEnvironmentModulePool": true/false and only be used during local development.
I am looking forward to hear your feedback.
9aoy commentedon Jun 30, 2025
@Ghostblad3 Thank you for your suggestion. Currently, when
rstest
executes a test file, it has module caching to prevent redundant file loading.However, between different test files, there is no caching for module loads due to test isolation. Fortunately, if a package is not marked as
external
, it will be bundled byrspack
(also known as transform), and its file content will be loaded into memory, preventing redundant disk reads.As for long-term caching optimizations,
rspack
's Persistent Cache may be supported inrstest
in the future.Ghostblad3 commentedon Jun 30, 2025
@9aoy Thank you! Could you elaborate why modules should not be shared between tests due to isolation? Modules are static, they never change. If X components uses a Material UI button I don't see a problem for the modules required by the button to be shared between the tests. Sharing them dramatically improved performance.
9aoy commentedon Jun 30, 2025
@Ghostblad3 Rstest runs every test file isolated by default. If your project has no side effects, you can set
isolate: false
to turn off isolation to optimize performance (There will be some errors that do not meet expectations, and we will fix them ASAP).Ghostblad3 commentedon Jun 30, 2025
@9aoy Does isolate: true will cache all modules loaded for each test so that they are not re-read from disk after a test finish and another one start?
9aoy commentedon Jul 1, 2025
When
isolate: false
is enabled and tests are within the same pool, module loading will be cached.derekdon commentedon Jul 11, 2025
Loving the suite.
Assuming the vi.mock type apis haven't been implemented yet right? ie. no matter what variants I try, they take no effect...
I just noticed a branch called
fix_mock
, with plugin tweaks... might explain it.fi3ework commentedon Jul 14, 2025
Oh,
rstest
as a alias ofrs
(or vice versa), is not merged into latest version now. You could users
as of now.travzhang commentedon Jul 18, 2025
Hi, I'm the author of CanyonJS, an end-to-end coverage collection platform designed for frameworks like Playwright. It works by using
babel-plugin-istanbul
to instrument code at the AST level and collects coverage data at runtime.Internally, we've extended this plugin to support advanced features like hit/map separation, allowing us to reduce bundle size and make coverage collection more production-friendly.
I'd love to contribute to the
rstest
project, specifically around its coverage functionality. I'm particularly interested in building a custom coverage provider similar to@rstest/coverage-istanbul
or@rstest/coverage-v8
, with support for code instrumentation and coverage report generation during test execution.I'm currently working on a minimal runnable demo and plan to share it before July 25.
Please let me know if you're open to contributions in this area—I'd be happy to help push coverage support forward in
rstest
. Thanks!fi3ework commentedon Jul 18, 2025
@travzhang Thanks for the sharing, Rstest's coverage ability is still under development, and the provider mechanism is not implemented as of now. We had planned to implementation it within this month or next.
Implementation coverage core functionality will be a rather bigger task, if you're interested in implementing it, please come up a RFC or issue to demonstrate the API design before start development.
Implementation CanyonJS' plugin after the coverage provider system implementing is sure feasible and welcomed. We'd love to help if you encounter any issue.
By the way, I'm interested in how you will integrate CanyouJS with Rstest? I only saw the recipes with Next/Vite/Lynx/RN, which are all app frameworks instead of testing framework.
travzhang commentedon Jul 20, 2025
#398
3 remaining items