Vue の単一ファイルコンポーネントをテストする手段を用意する

現状

.vue の描画を確かめる手段がこのリポジトリに無い。2026-09-18 に feat/merge-auth-collection の d8feaca で確かめたところ、次のとおりだった。

• @vue/test-utils・@nuxt/test-utils・happy-dom・jsdom・@testing-library/vue・@vitejs/plugin-vue のいずれも、リポジトリのルートと apps/web の node_modules に存在しない。
• ルートの vitest.config.ts の include は ['{apps,packages}/*/**/*.test.ts'] で、.vue を対象にしていない。

このため、表示条件の分岐や日時の書式のように、テンプレートの中で決まるものは型の検査でしか確かめられない。現状は、導出を apps/web/app/composables/ の関数へ切り出して純粋関数としてテストする形で迂回している（useListPagination.ts がその例）。

誰が何を誤るか

画面の分岐を変える人が、変更が描画に及ぼす影響をテストで確かめられない。切り出しで迂回できるのは導出だけで、テンプレートの v-if の条件やスロットの受け渡しはこの方法では確かめられないため、その部分の回帰は手で画面を開くまで出ない。

決めること

• 描画をテストする手段を入れるか、切り出しによる迂回を方針として明文化するか。
• 入れる場合、DOM の実装（happy-dom か jsdom）と、Nuxt の自動 import・コンポーネント解決をどう与えるか（@nuxt/test-utils を使うか、@vitejs/plugin-vue と手動のスタブで足りるか）。
• vitest.config.ts の include と環境の設定を、既存の *.test.ts の実行を遅くしない形にできるか。

直さずに残した理由

依存を足す判断で、実行時間と保守の負担が増える。描画のテストが要るかどうかは、上に挙げた「切り出しで迂回する」方針を続けるかどうかの判断と一体になっている。

Start with the root vitest.config.ts and apps/web/app/composables/useListPagination.ts, then inspect how existing *.test.ts files are run. Compare the repository's need for .vue rendering checks with the proposed extraction-based workaround and the listed test dependencies. Done means the project has a decided, documented testing approach and the relevant configuration or policy is in place.