フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識

投稿元：

レビューを見る

フロントエンド開発のテストをハンズオン形式で実習できる点がよい。
StorybookはUIデザインを確認できるツールとして認知していたが、UIコンポーネントテスト始めテストにも十分に使用できることを知れたのが良かった。
書籍内ではサンプルコードが抜粋で掲載だったりするので、全容は自分でコードを直接確認する必要がある。

投稿元：

レビューを見る

●テストの範囲
　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リファクタリングの難しさは依然として残ります。

投稿元：

レビューを見る

# ナウなフロントエンドのテストの基本が学べる一冊

## 面白かったところ

- reactの方のアプリケーションは、キツめのlintルールやStorybookへのコンポーネント切り出しがしやすかった点

- アサーション関数やモックのテクニックなど、公式ドキュメントとは別の角度で書かれていたのは親切だと思った

- Storybookのplay関数にインタラクションテストを移す際、様々なテクニックが必要で面白かった

## 微妙だったところ

- next.jsのアプリケーションの型解決が難しかった

## 感想

現実問題、テストするかどうかとは別の問題で、テストができるような設計でコードを書ける技術が求められている。

テストは永久に必要かどうかはさておき、書けたほうがエンジニアとして前線に立てる説はかなり濃厚である。そんなフロント何もわからんエンジニアに投げられた一冊としては、申し分ないクオリティかと思う。

JestだろうがVitestだろうが、Storybookのインタラクションテストだろうが、検証・担保したいものの書き方や考え方はそこまで変わらない。

だからこそこの本を踏み台にして、該当のコンポーネントで担保すべき価値を考えながら写経することはとても意味があると振り返る。

ただ、next.jsのアプリケーションの型パズル解決とE2Eのメンテナンスがめんどくさすぎて途中で放棄した。

気が向いたら、フロントの型パズル力もあげたい。

投稿元：

レビューを見る

フロントエンド開発におけるテスト手法についての本。
普段、テストをほぼ書いてない自分には、かなりハードルが高いように感じてしまった…。できる人はここまでやってるのかと驚き。
せめて、E2Eテストやビジュアルリグレッションテストまでやらなくても、ユニットテストぐらいは書けるようになりたいと思う。

なお、著者によるとテストを書いた方が時間は節約できるとのこと。本当、ちゃんとテスト書いておいたほうがうまくいくのだろうなと、一年ぐらい関わってるプロジェクトの現状を見て思う…。

テスト戦略モデルにおける、テスティングトロフィー型という概念は初めて知ったし、その概念には驚いた。テストの中で結合テストの比重を高めるという概念だそう。まあ、フロントエンドだとページ遷移したりAPIでデータとってきたりするから、結合テストが重要ということなのかな。

モックとかスタブとか、便利だけど使いこなすのはなかなか大変そうだなと思った。こういうのって、いまいち動作の仕組みが分かってないのだけど、どういう原理で動いているのだろう。

Testing Libraryというのは、何でタグの指定じゃなくてロールなんだと思った。タグの変更があること自体は、テストとして問題ないということかな。
今時のHTMLは、ロールについても意識しないといけないということなのかもしれない(WAI-ARIAについては、まだまだ分からないことが多い)。

JESTにカバレッジレポートの機能があるのは知らなかった。テストできていない範囲が分かるらしい。これは、便利。
ReactだとUIコンポーネントまで調査してくれるらしいけど、Vue.jsでもUIコンポーネント部分まで見てくれるのだろうか…(何となくできなさそうな気がする)。

ビジュアルリグレッションテストまではしなくても、Storybookを使うのはありかもしれないなぁ。このへんは、もう少し調べてみたい。

E2Eテストについては、大変そうだとしか思えない…。ただ、何かの手順で不具合が起きる場合、E2Eテストで再現するようにするのがいいのだろうなと思った。