Vitestを読む
nus3リポジトリ
nus3CONTRIBUTING.md
- pnpmワークスペースを使用したmonorepo
- VSCode使ってデバッグできる
- https://code.visualstudio.com/docs/editor/debugging
- Run and DebugからJavaScript Debug Terminalを選択
pnpm run test
nus3動作確認
rootでpnpm run devしつつ、pnpm run testでコアなテストケースは開発しながら確認できる。
また、任意のexamplesフォルダに移動し、pnpm run testを実行すればexamlesのテストも確認できる。
nus3rootのtestコマンドではtest/coreのテストを行なっており、その中でもbasic.test.tsがシンプルなテストになっているので動作確認するのに良さそう
cd test/core
pnpm run test test/basic.test.ts
# single run する場合
pnpm run test run test/basic.test.ts
デバッグ
VSCodeの場合、ブレークポイントを設定しRun and DebugからJavaScript Debug Terminalを選択、そのターミナル上でpnpm run testを実行するとブレークポイントに設定した部分で止まる。また1ステップずつ処理を確認できる
デバッグ中に変数の中身がVSCode上で確認できる。便利。
nus3packages
cd test/core
pnpm run test test/basic.test.ts
test/coreのbasic.test.tsを実行しつつ、packageが読み込まれる順に実装を眺める
vitest
nus3
vitest
./vitest.mjsがbinには指定されている
./vitest.mjsでは./dist/cli-wrapper.jsがimportされてる
nus3ビルドの設定をrollup.config.jsから見ると./dist/cli-wrapper.jsの元は'src/node/cli/cli-wrapper.ts'っぽい
'src/node/cli/cli-wrapper.ts'ではmain()が実行されている
nus3手元で実行してみるとimport('../cli')してる
'../cli'ではcreateCLI().parse()を実行してる
createCLI()
createCLI()ではcacというパッケージを利用している
cacはCommand And Conquerの略で、CLIアプリを作るためのライブラリぽい
nus3Vitestの場合、シンプルにテストを実行するならvitest runコマンドを実行する
このvitest runではrunが使われてそう
runの実装は以下で、start関数が呼ばれてる
引数であるcliFiltersには指定したテストファイルのパスが配列で格納されていた
['test/basic.test.ts']
start関数も同ファイルで定義されている
start関数の中ではstartVitest()が実行されている
nus3startVitest()の実装は以下
まずcreateVitest()で context を作ってそう
createVitest()の実装は以下
Vitest クラス
VitestPackageInstaller クラス
なんかサーバー作ってるけど、listen はしてない
ctx.start(cliFilters)の実装は以下
git からファイルの変更差分を検知してそう
テストの実行はここら辺かな？
テストを実行してそうthis.pool.runTests(paths, invalidates)
this.pool.runTests(paths, invalidates)の実装は以下
filesByPool.threadsの中にテストファイルのパスが格納されている
thread はcreateThreadsPoolで作られる。createThreadsPoolの実装は以下
pools[pool]!.runTests(specs, invalidate)が実行され
pools[pool]!.runTests(specs, invalidate)は以下の部分が実行される？
実態はここかな？
await pool.run(data, { transferList: [workerPort], name })
この pool は Tinypool
Node.js Worker Thread Pool をミニマムで作ったもの。pool を作った際にワーカーの内容を定義している。
worker の指定は以下でやっており、filename の値は'/Home/vitest/packages/vitest/dist/worker.js'
worker の実装はここ
nus3worker(threads?) の中で何が実装されているかを定義しているのは
この中で Tinypool にはpackages/vitest/src/workers.tsが渡されてる
以下 Claude3
Worker はプロセス間の並列処理、Threads はプロセス内の並列処理を行うためのモデル
プロセス間で並列処理をすることで同じメモリ領域を参照しない、しかし、プロセス間通信のオーバーヘッドは発生する。
逆に threads はスレッド間でメッセージングを使って直接通信できるが、メモリが共有されるため、データの競合が発生する可能性がある。
CPU バウンドと I/O バウンド
ディスクとの入出力は行わないが、計算が重いプログラムを CPU バウンド
ディスクとの入出力が多いプログラムを I/O バウンド
Worker Pool を使うことで複数のスレッドを効率的に並列実行できる
- 指定した数のスレッドをあらかじめ作成する。
- 実行したいタスクをキューに追加する。
- スレッドが空いている場合、キューからタスクを取り出して実行する。
- タスクが完了するとスレッドはプールに戻る。
- pool のスレッド数は動的に増減できる
Tinypool を作成するときもスレッド数を指定しており、ローカルで実行した場合、この数はどちらも 6 だった
TODO: Node.js の worker と threads を実装してみる
workers/threads.js
これはsrc/runtime/workers/threads.tsに実装がある
ThreadsBaseWorkerが export されている
この worker も data に詰め込まれた状態で pool.run が実行される
pool.run が実行されると
packages/vitest/src/runtime/worker.ts のrunが実行され、この中のworker.runTests(state)が実行される
worker.runTests(state)はの実装は以下でrunBaseTestsが実行される
runBaseTestsではimport('../runBaseTests'),で相対パスの位置にあるpackages/vitest/src/runtime/runBaseTests.tsが import され、その中のrunが実行される
runBaseTestsの中でrunの中のawait startTests([file], runner)部分が実際にテストを実行していそう
nus3
@vitest/runner
nus3テストを実行していそうなstartTestsは@vitest/runnerで定義されている
VitestRunner で公開されている API はドキュメントに乗ってる
startTests→runFiles→runSuite
runSuite→runSuiteChild→runTest
runSuiteChild→runTest
runTestの中ではgetFnでテスト対象の fn ?を取得して実行している
getFnは WeakMap に格納されている
以下 Claude3
WeakMap を使うことで Map とは異なり、キーとなるオブジェクトが参照されなくなると GC によりメモリが解放される
WeakMap を使うことでメモリりーすが低くなる。今回の Vitest の Test や Suite のように一時的に使われるものを WeakMap で格納することでメモリリークを防ぎつつオブジェクトの生存期間を気にしないで良くなる
getFnの返り値
fn.toString()
'(...args) => {
return Promise.race([fn(...args), new Promise((resolve, reject) => {
var _a;
const timer = setTimeout(() => {
clearTimeout(timer);
reject(new Error(makeTimeoutMsg(isHook, timeout)));
}, timeout);
(_a = timer.unref) == null ? void 0 : _a.call(timer);
})]);
}'
これはwithTimeoutの実装
sefFnしているのはcreateSuiteCollectorの中
setFnするタイミングはデバッグの call stack を見ると
- packages/vitest/src/runtime/runBaseTests.ts の
run()時のstartTests() - packages/runner/src/collect.ts の
collectTests() - runner.importFile
- VitestTestRunner.importFile
- ViteNodeRunner.executeId
- ViteNodeRunner.cachedRequest
- ViteNodeRunner.directRequest
- ViteNodeRunner.runModule
テストコードで使うsuiteは createSuiteCollector を実行してる。
createSuiteCollector、createSuite、suite
このcreateSuiteCollectorの中でsetFnしており、withTimeoutの第一引数に実行されるテスト関数が渡されている
第一引数はwithFixtures(handler, context)で
手元で実行してみると以下の部分のように handler(fn)を実行している
この handler(fn) は以下のようになっている
handler.toString()
'async () => {
__vite_ssr_import_0__.assert.equal(Math.sqrt(4), __vite_ssr_import_1__.two);
__vite_ssr_import_0__.assert.equal(Math.sqrt(2), Math.SQRT2);
__vite_ssr_import_0__.expect(Math.sqrt(144)).toStrictEqual(12);
}'
ここまでくるとテストが単体で実行できるようになっていそう
このhandlerはcreateSuiteCollectorの中で定義されている
TODO: handlerを定義している方法を調べるところから
nus3テスト実行時(startTests)に、対象のテストを取得するcollectTests
collectTestsの実装箇所
pathe
あらゆる環境で使えるファイルパスモジュールで UnJS の一つ
UnJS は、Nuxt 開発チームが中心となって開発・メンテナンスされている、あらゆる JavaScript フレームワーク上で統一的に動作するユーティリティーツール・ライブラリ群
対象のテストファイルをrunner.importFile(filepath, 'collect')してる
importFileではthis.__vitest_executor.executeId(filepath)が実行される
this.__vitest_executor.executeId(filepath)は手元ではViteNodeRunnerのexecuteIdが実行される
Runner の定義はここ
TODO: どのように Runner を定義しているのか
executeIdではcachedRequestを実行
循環参照を防ぐ処理とかしてそう
directRequestが実行される
directRequestの定義場所
directRequestの中で対象のテストファイルパスに対して、await this.options.fetchModule(id)を実行してる
this.options.fetchModule()の実装場所
this.options.fetchModule()の返り値のcodeの値
const __vite_ssr_import_0__ = await __vite_ssr_import__(
"/@fs/Users/nus3/dev/fork/vitest/packages/vitest/dist/index.js",
{ importedNames: ["assert", "expect", "it", "suite", "test"] }
);
const __vite_ssr_import_1__ = await __vite_ssr_import__("/src/submodule.ts", {
importedNames: ["two"],
});
const __vite_ssr_import_2__ = await __vite_ssr_import__("/src/timeout.ts", {
importedNames: ["timeout"],
});
__vite_ssr_import_0__.test("Math.sqrt()", async () => {
__vite_ssr_import_0__.assert.equal(Math.sqrt(4), __vite_ssr_import_1__.two);
__vite_ssr_import_0__.assert.equal(Math.sqrt(2), Math.SQRT2);
__vite_ssr_import_0__.expect(Math.sqrt(144)).toStrictEqual(12);
});
TODO: vm.runInContextを使ってみる
テスト対象のファイルやテストで使われるモジュールを実行できる形にトランスパイルしてそう
this.options.fetchModule()がトランスパイルしてそうなので中身をもっとみる
this.options.fetchModule()は何回か呼ばれてそう
サブモジュールをthis.options.fetchModule()した時の返り値
const two = 1 + 1;
Object.defineProperty(__vite_ssr_exports__, "two", {
enumerable: true,
configurable: true,
get() {
return two;
},
});
rpc().fetch(id, getTransformMode())の返り値にはトランスパイルされた後のコードが生成されてる？
rpc()は何なのか
rpc は Proxy オブジェクト
rpc 周りの実装はここにありそう
vitest/packages/vitest/src/runtime/rpc.ts
以下 Claude3
rpc は、Remote Procedure Call(リモートプロシージャコール)の略です。
これは、プログラム間でデータを交換したり、他のプログラムの機能を利用したりするための技術の一種です。
Vitest において rpc は Worker と Runner の間での通信に使われています。
Worker: テストを実行する役割を持つプロセス
Runner: Worker の管理やテスト実行の調整をする親プロセス
rpc を使うことで、Runner から Worker にテストの実行を指示したり、Worker から Runner にテスト結果を送ったりと、プロセス間でデータのやり取りができます。
具体的には、createRuntimeRpc という関数で rpc のインスタンスを作成し、それを介して Worker と Runner が通信を行なっているようです。rpc の実装には birpc というライブラリが使われているみたいですね。
rpc はクライアント・サーバー形式の分散システムでよく使われる技術概念ですが、Vitest ではプロセスレベルでのメッセージングにも活用されているということになります。
birpcというライブラリが使われている
このrpcを使ってる箇所でコメントが記載されており
Claude さんが言ってるように、ワーカー(Worker、threads、子プロセス)とメインスレッド間の通信に使用される
が、トランスパイルが実施されるタイミングがわからぬ...
トランスパイル後のコードで使われている__vite_ssr_import__を全文検索すると以下の部分でのみ使われていた
TODO: packages/vite-node/src/client.ts の部分を読めば、どこでトランスパイルしてるのかわかるかも
nus3
vite-node
Node.jsでのテスト実行時にトランスパイルをやってそうなパッケージ
nus3Vite でサーバー作ってその中で fetchModule を定義している？
vite-nodeでは server と client があって、server 側でトランスパイル、client 側で対象ファイルを実行してるんか？
トランスパイルをしてそうな箇所
ViteDevServer の transformRequest を使っている
/**
* プログラムで URL を解決、読込、変換して、HTTP リクエストパイプラインを
* 経由せずに結果を取得します。
*/
transformRequest(
url: string,
options?: TransformOptions,
): Promise<TransformResult | null>
手元で確かめたトランスパイル後のコード
const __vite_ssr_import_0__ = await __vite_ssr_import__(
"/@fs/Users/nus3/dev/fork/vitest/packages/vitest/dist/index.js",
{ importedNames: ["assert", "expect", "it", "suite", "test"] }
);
const __vite_ssr_import_1__ = await __vite_ssr_import__("/src/submodule.ts", {
importedNames: ["two"],
});
const __vite_ssr_import_2__ = await __vite_ssr_import__("/src/timeout.ts", {
importedNames: ["timeout"],
});
__vite_ssr_import_0__.test("Math.sqrt()", async () => {
__vite_ssr_import_0__.assert.equal(Math.sqrt(4), __vite_ssr_import_1__.two);
__vite_ssr_import_0__.assert.equal(Math.sqrt(2), Math.SQRT2);
__vite_ssr_import_0__.expect(Math.sqrt(144)).toStrictEqual(12);
});
/src/submodule.ts側
const two = 1 + 1;
Object.defineProperty(__vite_ssr_exports__, "two", {
enumerable: true,
configurable: true,
get() {
return two;
},
});
s;
サブモジュールでは__vite_ssr_exports__が使われていて、トップレベルのモジュールでは__vite_ssr_import__を使ってモジュールを import している。
ViteNodeRunner 側では context に import や export のために必要なものを格納してから ViteNodeServer 側でトランスパイルされた関数を vm で実行している
nus3TODO: ViteのtransformRequestを使いつつ、vite-nodeの部分を自作してみる