ブログ記事
テストが書きづらいのは設計の問題——後悔しないためのVueコンポーネント設計
Vue.js で SPA を開発していると、コンポーネントが肥大化してきた頃に「どう分割すべきか」の基準がなくなる。本書『後悔しないためのVueコンポーネント設計』は、全64ページという薄さに実務直結の設計基準を詰め込んだ一冊だ。著者は Vue.js バージョン 0.10 から採用してきたフロントエンドエンジニアで、現場感覚の説得力がある。
1. 「テストが書きにくい」は設計の警告だ
本書の核心となる主張は「テストコードの書きやすさが設計品質の客観的な指標になる」という点だ。
単体テストを書こうとして大量のモック作成や複雑な初期化処理が必要になるコンポーネントは、過剰な依存関係や複雑な内部状態を抱え込んでいる。このテスト実装時のストレスが、コンポーネントの結合度が高すぎることを検知するセンサーになる。
テストがシンプルに書けるようにコンポーネントを整理していくプロセスが、疎結合で再利用性の高い設計へと実装を導く。設計とテストは別々のタスクではなく、同じ作業の表と裏だ。
2. 4つの層でデータの流れを整理する
flowchart TD
P["pages\nページ全体の構成"] --> C["containers\n状態管理・外部データ接続"]
C --> CO["components\n複数の basics を組み合わせた部品"]
CO --> B["basics\nボタン・ラベルなど\n状態を持たない最小部品"]
style P fill:#e8f4fd,stroke:#4a9eda
style C fill:#fff8e1,stroke:#f5a623
style CO fill:#e8f8e8,stroke:#4caf50
style B fill:#f3e5f5,stroke:#9c27b0
本書は UI をディレクトリ単位で4層に分類するアプローチを提案している。
- basics：ボタンやラベルなど基本の UI パーツ。状態を持たない
- components：複数の basics を組み合わせた再利用可能なパーツ
- containers：状態管理や外部データとの接続を担う
- pages：ページ全体の構成
描画に専念するステートレスな部品と、状態管理や外部連携を担うステートフルな部品を明確に分離することで、データの流れが一方通行に整理される。開発者ごとの実装パターンのばらつきが抑えられ、レビューや統合にかかる時間が減る。
3. 長期的な保守性を損なうアンチパターンを名指しで批判
一度作成したコンポーネントの修正が他の箇所に予期せぬ影響を与える場合、そこには設計の問題が潜んでいる。本書は避けるべきパターンを具体的に示している。
- Props に対する不適切な型指定
- 親子コンポーネント間での無秩序な値の変更
- Vuex Store の getter への不必要な依存
- ライフサイクルフックへのビジネスロジックの直書き
コンポーネントが処理する状態の範囲を最小化する設計を習慣付けることが、不具合の発生率を下げ、技術的負債の蓄積を防ぐ防御策だと本書は説く。
なお、本書の技術環境は Vue 2・Vuex・Options API を前提としている。Vue 3（Composition API・Pinia）への移行が進んだプロジェクトでは、コード構文を直接流用することはできない。ただし、設計の原則——テスト容易性の指標化、層の分離、アンチパターンの排除——は現代の Vue 開発にも通じる。
4. この本が効く場面
「このロジックは components に書くべきか、containers に寄せるべきか」——複数人での Vue プロジェクトでこの判断が毎回その場任せになっていると、人ごとに実装パターンが割れ、レビューと統合のたびに時間を取られていく。本書の4層分類は「どこに何を置くか」をディレクトリ規約として固定するため、置き場所の議論が個人の好みではなく規約への適合で決着するようになる。チームの設計基準を整えたいリーダーには、そのまま持ち込める判断材料になる。
もう一つ効くのは「単体テストを導入したいが、どのコンポーネントの何をテストすべきかが決められない」という状況だ。テストしやすい形へコンポーネントを整える基準に、Jest と vue-test-utils を使った実際のテストコードの書き方が実例で続くので、テスト導入の最初の足場として機能する。
5. 向いている人・向いていない人
向いている人：
- Vue での SPA 開発は一通りこなせるが、コンポーネントの分割粒度やロジックの置き場所を毎回その場で決めており、揃った判断基準がほしい
- 複数人のプロジェクトで実装パターンが人ごとにばらつき、チームの設計規約を整備する立場にある
- 単体テストをこれから導入したいが、どのコンポーネントの何をテストすべきか、範囲の決め方が分からない
向いていない人：
- Vue の基本文法をこれから学ぶ人。本書は基礎的な構文説明を省いているため、先に『Vue 3 フロントエンド開発の教科書』のような基礎書を済ませてからの方が効く
- 単体テストの運用がすでに定着していて、その先の高度なテスト戦略を求める人。本書の射程はコンポーネント分類と単体テストの基礎にある（詳細は次節）
6. 64ページに書かれていないこと
本書の割り切りは明確だ。基礎的な構文説明を省き、テストの書き方とアンチパターンの排除に的を絞ることで、64ページで設計の土台を固める構成になっている。短時間で要点を吸収したい実務者には、この薄さ自体が利点になる。
裏返せば、扱わない領域もはっきりしている。ドメインロジックが複雑に絡み合う大規模アプリでのモック化の具体的な手順や、結合テスト・E2E テストまで組み合わせたテスト戦略の全体像は、紙幅の制約上カバーされていない。単体テストと分類の土台を本書で固め、その先のテスト戦略は別の本で補う——この分担を前提に手に取ると、期待とのずれがない。
7. 全7章の歩き方
構成は、第1〜2章がテストと設計の関係、第3〜4章がコンポーネントの分類とディレクトリ構成、第5章がテスト対象の決め方、第6〜7章が環境構築と実践、という流れだ。64ページの分量なので、まず通して読んで全体の論理をつかみ、それから手元のプロジェクトに当てはめる読み方が合う。
前述の通り本書の技術環境は Vue 2 世代で、その影響が最も出るのが第6章「テスト実行環境の構築」だ。Vue 3 系のプロジェクトなら、この章は手順書としてではなく「何を整えればテストが回るか」を確認するチェックリストとして読み、実際の構築は Vitest など現行ツールの公式ドキュメントに置き換えるのが現実的だ。
8. 読後の次の一歩
次に進む方向は、関心の向きで分かれる。テストの側を深めたいなら『フロントエンド開発のためのテスト入門』へ。テストの書きやすさを設計の指標にする本書の視点を引き継ぎつつ、テスト対象の選び方や粒度の考え方を、結合テストや E2E も含めた戦略へ広げられる。本書が紙幅の都合で扱わなかった領域を埋める位置づけでもある。
設計の関心が単一アプリの内側から複数チーム・複数アプリの分割へ広がったなら、『マイクロフロントエンド』が次の課題を扱う。チームごとに独立して開発・デプロイできる UI をどう合成するかという、組織の規模に向き合う設計だ。
実務での最初の一歩は、手元のプロジェクトで最もテストが書きづらそうなコンポーネントを1つ選び、実際に単体テストを書いてみること。必要になるモックの数と初期化処理の複雑さが、本書の主張——テストの書きにくさは設計の警告——を体感する一番の近道になる。
筆者の体験から
Vueの管理画面がだんだん肥大化し、フィルタ条件を使わない孫コンポーネントにまでpropsで渡していた時期に本書を選んだ。単体テストを書こうにもモックの準備だけで心が折れ、componentsとcontainersのどちらにロジックを書くかも毎回レビューで揉めていた。
読み終えてからは「テストが書きにくいこと自体が設計の警告」という捉え方をレビューの口癖にした。一覧・フィルタ・ページネーションを抱えたコンポーネントも、状態をcontainer側に寄せ見た目だけのテーブルをcomponents側に切り出すと、必要なモックが5、6個から2個程度まで減り、置き場所の議論もレビューから消えた。
ただし第6章の環境構築はVue 2・Options API前提のままで、Composition APIへの移行を進めていたチームではチェックリスト程度にしか使えず、componentsとcontainersの境界も実際には割り切れない場面がたびたびあった。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有