The Cost of the DOM ― jsdom / happy-dom とVitest Browser Modeの実行時間を分解する

コンポーネントのテストをjsdom (happy-dom) で動かすか、実ブラウザで動かすか。 純粋関数やhooksのテストにDOMは要りませんが、コンポーネントは視覚的なものなので、動作やデザインの確認には実ブラウザが必要です。

近年はVitest Browser Mode、そしてStorybook Vitest Addonにより、コンポーネントのテストを簡便に実行できる環境が実現されました。 それでも実ブラウザは重いという前提から、非視覚的なテストにjsdom (happy-dom) を使い分けることが推奨されています。 また実業務において、テストの増加に伴いStorybookのCIが他と比べて時間がかかることが課題になってきました。

この推奨に従うと、コンポーネントテストの実装環境が2つになり、どちらで書くかという曖昧な判断が発生してしまいます。 その選択の一貫性の管理は、Coding Agentにより生成されるコードの量が増えるほど難しくなります。 しかし実ブラウザ実行によるオーバーヘッドがどのように生まれるのかについて、これまであまり掘り下げられてきませんでした。

本セッションでは、同じテストをVitest + jsdomやStorybook Vitest Addonなど異なるセットアップで実際に実行し、 実行環境の起動、コード変換、モジュール読み込み、テスト実行、並列化といった段階に分けて測定することで、 「ブラウザは重い」という印象を実際のコスト構造に置き換え、そのうえで実装環境を二重化させない構成が成り立つのかを検討します。

なお測定には、オープンソースのUIライブラリのテストを各セットアップ向けに変換したものを利用します。