感情タグ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リファクタリングの難しさは依然として残ります。
