1件あたり0.10%の確率でたまに落ちるとします。50件なら一式が赤くなるのは4.8%です。
1000件では62.8%になります。1件あたりは変わっていないのに、一式は当てになりません。
変更のたびに走らせる前提なら、一式が当てになるかが重要になります。件数が効きます。
Vitestは、変更のたびに走らせることを前提にしています。公式は監視の動作は既定で有効になっており、Viteが押し進める開発を第一とする体験に沿っていると述べています。
頻繁に走らせるなら、赤が本物かどうかが効きます。件数を変えて数えました。
各テストが独立に、決まった確率でたまに落ちるとしました。一式を2万回まわしています。
一式を 20000回まわし、本当は問題がないのに赤くなる割合を数える 各テストは独立に、決まった確率でたまに落ちるものとした たまに落ちる確率 50件 200件 1000件 3000件 0.01% 0.5% 2.1% 9.0% 26.0% 0.10% 4.8% 17.8% 62.8% 95.0% 0.50% 22.1% 62.5% 99.3% 100.0%
1件0.10%の行を見てください。50件なら4.8%、1000件では62.8%です。
1件あたりの確率は変えていません。件数だけで13倍になりました。
62.8%ということは、赤くなった回の多くが本物ではないということです。
そうなると、赤を見ても手が止まりません。まず走らせ直すという動きになります。
変更のたびに走らせる道具ほど、この問題が効きます。回数が多いぶん、赤を見る機会も増えるためです。
1件あたりが同じでも、件数が増えると一式が当てにならなくなる。
Watch mode is enabled by default, aligning itself with the way Vite pushes for a dev first experience.原文Vitest 公式ドキュメント「Why Vitest」 この内容の有効期限2027-02-18
落ちたら試し直す設定は効きます。ただし、毎回は出ない不具合も同じ割合で消えます。
Vitestは走らせる役を担う道具です。公式はVitestは、Viteを使う企ての選ばれる実行役として、またViteを使わない企てにとっても堅実な代わりとして、自らを位置づけることを目指すと述べています。
走らせる役が持つ設定のひとつが、落ちたら試し直すことです。その効き方を数えました。
一式 1000件。1件あたり 0.20% の確率でたまに落ちる 落ちたテストは決めた回数まで再実行し、すべて落ちたときだけ赤にする（20000回まわした） 再実行の上限 誤って赤くなる割合 不具合100%を捕まえる 不具合50%を捕まえる 不具合20%を捕まえる 1回 86.71% 100.0% 50.0% 20.0% 2回 0.47% 100.0% 25.0% 4.0% 3回 0.00% 100.0% 12.5% 0.8%
上限2回で、誤検知は86.71%から0.47%になります。184分の1です。
ところが右の列も同時に下がります。5割の確率で出る不具合は50.0%から25.0%へ、同じ割合で見逃されます。
偶然の失敗も、毎回は出ない不具合も、「再実行したら通った」という形が同じです。区別できません。
だから再実行は、両方を同じ式で消します。片方だけを消すことはできません。
毎回出る不具合だけは残ります。左から2列目が100.0%のままなのがそれです。
同じ形の釣り合いはE2Eテストの記事でも扱いました。再実行は、確率で出るものすべてに同じように効きます。
Vitest aims to position itself as the Test Runner of choice for Vite projects, and as a solid alternative even for projects not using Vite.原文Vitest 公式ドキュメント「Why Vitest」 この内容の有効期限2027-02-18
組み立てに使う設定をそのまま使えます。だから、設定を二重に持たずに済みます。
Vitestの土台は明示されています。公式はVitestはViteによって支えられていると述べています。
支えられているので、変換の設定を共有できます。公式もその利点を説明しています。
試験のあいだにファイルを変換するのにViteの開発用の受け口を使う。そうすることで、原始のファイルの変換という込み入った処理を扱わずに済む単純な実行役を作れる、という説明です。
1番目が実務で効きます。組み立てでは通るのに試験では通らない、という状態が起きません。
変換を共有すると、走らせ直しが速くなります。変わった分だけを作り直せるためです。
その範囲はViteの記事で測っていて、中央値3個・99%点282個でした。速い場合と遅い場合の幅が大きい形です。
速くなると走らせる回数が増えます。そのぶん、前の節の誤検知に当たる機会も増えます。速さと当てになることは別の話です。
各テストが独立に、決まった確率で落ちるという前提を置いています。実際には、同じ原因で複数のテストが同時に落ちることが多く、その場合は一式が赤くなる割合がここより低くなります。1件あたりの確率も置いた値です。再実行の右3列は、捕まえる確率を繰り返し乗じた計算で出しています。ここで見せているのは、件数が増えると一式が当てにならなくなること、再実行が誤検知と不具合を同じ式で消すことの2つです。
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る