あらすじ
現場で役立つテスト手法を基礎から解説！
「どこから」「どうやって」手をつければよいかわかる
本書は、Webアプリケーション開発に携わるフロントエンドエンジニアを対象に、「テスト」の基本知識と具体的な実践手法を解説した書籍です。
高度な機能を画面上で提供する現代のWebアプリケーションでは、その品質や保守性を担保するうえで、フロントエンドにおける自動テストが重要な役割を持ちます。
本書はそんな「フロントエンドにおけるテスト」をテーマに、基本的なテストコードの書き方や、目的に応じたテスト手法・ツールの使い分け方を解説します。「UIコンポーネントテスト」や「ビジュアルリグレッションテスト」など、フロントエンドならではの具体的なテスト課題に重点を置いており、基本から実践まで必要な知識を体系的に身につけることができます。
解説はサンプルWebアプリケーション（Next.js）を舞台にしたハンズオン形式で進みます。「アクセシビリティの改善」や「CIでのテスト実行」といったトピックもフォローしているので、開発現場で役立つ実践的な知識・ノウハウがきちんと身につく一冊です。
■こんな方におすすめ
・テストの必要性は理解しているが着手できていない
・それなりに開発経験はあるがテストを書いたことがない
・現在取り組んでいるテスト手法が最適かわからない
■本書で取り上げるテストツール
Jest／Testing Library／Storybook／reg-suit／Playwright...etc
■目次
第1章 テストの目的と障壁
第2章 テスト手法とテスト戦略
第3章 はじめの単体テスト
第4章 モック
第5章 UIコンポーネントテスト
第6章 カバレッジレポートの読み方
第7章 Webアプリケーション結合テスト
第8章 UIコンポーネントエクスプローラー
第9章 ビジュアルリグレッションテスト
第10章 E2E テスト
【ダウンロード付録】
付録A GitHub Actionsで実行するUIコンポーネントテスト
付録B GitHub Actionsで実行するE2Eテスト
※翔泳社の書籍サイトからPDFをダウンロードできます。
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
Posted by ブクログ
フロントエンド開発のテストをハンズオン形式で実習できる点がよい。
StorybookはUIデザインを確認できるツールとして認知していたが、UIコンポーネントテスト始めテストにも十分に使用できることを知れたのが良かった。
書籍内ではサンプルコードが抜粋で掲載だったりするので、全容は自分でコードを直接確認する必要がある。
Posted by ブクログ
# ナウなフロントエンドのテストの基本が学べる一冊
## 面白かったところ
- reactの方のアプリケーションは、キツめのlintルールやStorybookへのコンポーネント切り出しがしやすかった点
- アサーション関数やモックのテクニックなど、公式ドキュメントとは別の角度で書かれていたのは親切だと思った
- Storybookのplay関数にインタラクションテストを移す際、様々なテクニックが必要で面白かった
## 微妙だったところ
- next.jsのアプリケーションの型解決が難しかった
## 感想
現実問題、テストするかどうかとは別の問題で、テストができるような設計でコードを書ける技術が求められている。
テストは永久に必要かどうかはさておき、書けたほうがエンジニアとして前線に立てる説はかなり濃厚である。そんなフロント何もわからんエンジニアに投げられた一冊としては、申し分ないクオリティかと思う。
JestだろうがVitestだろうが、Storybookのインタラクションテストだろうが、検証・担保したいものの書き方や考え方はそこまで変わらない。
だからこそこの本を踏み台にして、該当のコンポーネントで担保すべき価値を考えながら写経することはとても意味があると振り返る。
ただ、next.jsのアプリケーションの型パズル解決とE2Eのメンテナンスがめんどくさすぎて途中で放棄した。
気が向いたら、フロントの型パズル力もあげたい。
Posted by ブクログ
●テストの範囲
Webアプリケーションコードは、様々なモジュールを組み合わせて実装します。例えばを提供するためには、次のような一連のモジュール(システム)が必要です。
①ライブラリが提供する関数
②ロジックを担う関数
③UIを表現する関数
④Web API クライアント
⑤APIサーバー
⑥DBサーバー
フロントエンドの自動テストを書くとき、この①～⑥のうち「どこからどこまでのカバーしたテストであるか」を意識する必要があります。Webフロントエンド開発におけるテストの範囲(テストレベル)は、概ね次の4つに分類されます。
静的解析
TypeScriptやESLintによる静的解析です。一つ一つのモジュール内部検証だけでなく、というように隣接するモジュール間連携の不整合」に対して検証します。
単体テスト
②のみ、③のみ、というように「モジュール単体が提供する機能」に着目したテストです。立した検証が行えるため、アプリケーションにはめったに発生しないケース(コーナーケース)の検証に向いています。
結合テスト
①~④まで、②～③までというように「モジュールをつなげることで提供できる機能」に着目したテストです。範囲が広いほどテスト対象を効率よくカバーすることができますが、相対的にざっくりとした検証になる傾向があります。
E2Eテスト
①~⑥を通し、ヘッドレスブラウザ+UIオートメーションで実施するテストです。最も広範囲な結合テストともいえるもので、アプリケーション状況に忠実なテストです。
●テストの目的
テストは目的によって「テストタイプ」に分類されます。ソフトウェアテストで有名なテストタイプが「機能テスト、非機能テスト、ホワイトボックステスト、リグレッションテスト」です。
テストタイプは検証目的に応じて設定され、テストタイプごとに適したテストフールが存在します。ツール単体で実現するものもあれば、組み合わせることで実現するものもあります。Webフロントエンドテストにおいて代表的なテストタイプとしては、次のものが挙がります。
機能テスト(インタラクションテスト)
開発対象の機能に不具合がないかを検証するのが「機能テスト」です。Webフロントエンドにおける開発対象機能の大部分は、UIコンポーネントの操作(インタラクション)が起点となります。そのため、インタラクションテストが機能テストそのものになるケースが多く、重要視されます。本物のブラウザAPIを使用することが重要なテストの場合、ヘッドレスプラウザ+UIオートメーションを使用して自動テストを書きます。
非機能テスト(アクセシビリティテスト)
非機能テストのうち、心身性に隔てのない製品を提供できているかという検証が「アクセシビリティテスト」です。 近年、Webアクセシビリティに関するAPIが様々なプラットフォームで展開されており、自動テストでも客観的に判定できる環境が整っています。
リグレッションテスト
特定時点から、前後の差分を検出して想定外の不具合が発生していないかを検証するテストが「リグレッションテスト」です。Webフロントエンドにおける開発対象の大部分が見た目(ビジュアル)を持つUIコンポーネントであることから、「ビジュアルリグレッションテスト」が重要視されます。
実行速度：早い→遅い
本番環境の再限度：低い→高い
UIコンポーネントテスト＠jsdom(Node.js) Jestなど
UIコンポーネントてすと＠ブラウザ Storybook
E2Eテスト＠ブラウザ Playwright
■ビジュアルリグレッションテストの必要性
●スタイル変化を検知することの難しさ
CSSによるスタイル定義は、積み重ねられたプロパティから算出されます。適用されるプロパティは「詳細度」や「読み込み順」で決まるだけでなく、グローバル定義の影響を受けます。そのため「見た目の変化」は、ブラウザ越しに目視で確認する必要がありますが、全てのページで影響が及んでいないかどうか、判断するのは至難の業です。すでにある定義を変更/削除することには、意図せぬリグレッションを引き起こす可能性がつきまといます。この対処としてとり得るのは「すでにある定義には触れない」という、ネガティブなアプローチです。リファクタリングに取り組めない不健全なCSS定義は、その場しのぎの積み重ねになってしまいます。
SPAは、小さな共通UIコンポーネントから画面を構築することが基本です。UIコンポーネントを組み上げて画面構築するフローは、ブロックを組み上げる様相と近しく「コンポーネント指向」と呼ばれています。コンポーネント指向はロジックの一元管理だけでなく、繰り返しになり得るスタイル定義を一元管理することができます。画面構築に規律をもたらす一方で、多くの画面は多くの共通UIに依存することになります。つまり、共通UIのスタイル変更は、多くの画面に影響を及ぼすことになります。コンポーネント指向だからといって、CSSリファクタリングの難しさは依然として残ります。
