メニュー
Debug Rstest issues systematically, including performance regressions. First determine whether the slowdown is in build startup or test execution, then run controlled config or code experiments and compare before/after timings.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/rstackjs/agent-skills --skill rstest-debuggingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
SOC 職業分類に基づく
| name | rstest-debugging |
| description | Debug Rstest issues systematically, including performance regressions. First determine whether the slowdown is in build startup or test execution, then run controlled config or code experiments and compare before/after timings. |
Use this skill when Rstest is slower than expected, slower than Jest or Vitest, slower than a previous Rstest baseline, or when users report that tests spend a long time before starting.
The goal is not to guess a root cause from config names alone. First identify where time is being spent, then change one variable at a time and compare the result.
Before changing config or code:
node, jsdom, happy-dom, browser mode), and relevant worker settings.Common baseline commands:
npx rstest run path/to/test-file.test.ts
npx rstest --reporter=verbose path/to/test-file.test.ts
pnpm rstest path/to/test-file.test.ts
If the problem is reported as “there is a long pause before tests even start”, treat that as a build or startup hypothesis until measurements prove otherwise.
Split the investigation into one of these buckets:
DurationUse these tools in order:
--trace when the time distribution is unclearnpx rstest run --trace
--trace produces a Perfetto-compatible trace with per-phase, per-suite, and per-case slices. Use it to answer: is the time concentrated in prepare or build phases, or inside test execution?
DEBUG=rstest for build-stage cluesDEBUG=rstest npx rstest run
Focus on:
dist/.rstest-tempnpx rstest --reporter=verbose
Use this to find the slow file, suite, or case before reaching for a profiler.
For jsdom and happy-dom, Rstest bundles third-party dependencies by default. That often explains reports like “Rstest is slow before tests even start”.
Check these first:
Run one experiment at a time, and rerun the exact same baseline command after each change.
For non-browser mode, try:
import { defineConfig } from '@rstest/core';
export default defineConfig({
testEnvironment: 'jsdom',
output: {
bundleDependencies: false,
},
});
Compare:
dist/.rstest-temp sizeIf only a few dependencies dominate the graph, prefer a smaller change:
import { defineConfig } from '@rstest/core';
export default defineConfig({
output: {
externals: ['react', 'lodash'],
},
});
If a previous Jest setup used moduleNameMapper to stub CSS or SCSS with identity-obj-proxy, compare that behavior explicitly instead of assuming the native Rstest path is equivalent:
import { defineConfig } from '@rstest/core';
export default defineConfig({
tools: {
rspack: (config, { rspack }) => {
config.plugins ??= [];
config.plugins.push(
new rspack.NormalModuleReplacementPlugin(
/\.(css|less|scss)$/,
'identity-obj-proxy',
),
);
},
},
});
Only keep this if the tests do not depend on real style behavior and the timing improvement is measurable.
If startup is still slow and the expensive part is unclear, use Rsdoctor to see whether time is dominated by entries, loaders, plugins, or dependency chains.
Once startup is acceptable and execution remains slow, stop tuning bundling first. Focus on the runtime path.
Investigate in this order:
--trace to see whether time is spent in setup hooks, the test body, retries, or teardown.samply for CPU time distribution--heap-prof for memory allocation--inspect for step-through debuggingCommon runtime fixes to test one by one:
beforeEach when it can be shared safely.pool.maxWorkers settings if worker oversubscription or contention is suspected.Every optimization attempt must follow this loop:
Report the result in a compact table when possible:
| Change | Cold run | Warm run | Outcome |
|---|---|---|---|
| Baseline | |||
output.bundleDependencies: false | |||
CSS stub via NormalModuleReplacementPlugin |
Do not stack multiple “maybe faster” changes before measuring. That destroys the ability to attribute the result.
Debug Rstack ecosystem CI failures for Rspack, Rsbuild, Rslib, Rspress, Rstest, and Rsdoctor, then attribute the real source PR or downstream change. Always use this skill when the user mentions Rstack eco-ci, rstack-ecosystem-ci, a suite turning red, a downstream regression, a green-to-red pivot, canary bisect, or daily eco-ci triage — even if they only ask "why is this suite failing", "which PR broke it", or "is this upstream project's fault". Use it to avoid over-blaming the first upstream commit that appears red in status data.
Benchmark and iteratively improve agent skills with Codex CLI or Claude Code by generating eval cases, comparing skill-guided vs baseline runs, grading outcomes, and recording actionable reports under skills-test/{skill-name}.
Migrate Jest or Vitest projects to Rstest. Use when asked to move from Jest/Vitest to Rstest, replace `jest`/`vi` APIs with `@rstest/core`, translate config into `rstest.config.ts`, update scripts/coverage/setup/mocks/snapshots/projects, or diagnose config-loading warnings, migration failures, and memory/performance regressions caused by Rstest's Rsbuild/Rspack execution model, DOM dependency bundling, runtime-mocked module build graphs, or version skew.