はじめに
言われるままにテストコード書いているだけでしたが、
そろそろきちんと勉強して自分なりの考えを整理しようと思う。
※Bingにも相談してブラッシュアップしていければ...
テスト戦略作成
１．テスト戦略のためのチェックリスト
| No | ポイント | 概要 | |
|---|---|---|---|
| ▢ | 1 | トレードオフスライダー作成 | 観点：ベースコスト(金額・時間・人)/品質コスト/学習コスト/実装コスト/実行時間コスト) |
| ▢ | 2 | 品質方針の明確化 | ※プロジェクト規模/納期を踏まえたスコープを... |
| ▢ | 3 | なぜテストをするのか？ | バグやデグレを防ぐ リファクタリング 開発効率/体験向上 |
| ▢ | 4 | 何をテストするのか？ | ※後述のテスト範囲やテスト観点参照 |
| ▢ | 5 | どうやってテストをするのか？ | ※後述のテストの種類参照 |
| ▢ | 6 | どこまでテストをするのか？ | ※No4,5を踏まえて取捨選択 |
| ▢ | 7 | 保守/運用方法 | テストコードの保守/運用コストを意識しないと自滅することに... |
- テストがなく、リファクタリングに不安がある場合
- レスポンシブレイアウトを含むプロジェクトの場合
- データ永続層を含めたE2Eテストを行いたい場合
【テストと品質の現状分析結果-format】
| テストの種類 | 守りたい品質 | 網羅性 | 実行タイミング | マトリクス(pt) | Input | Output | As-Is | To-Be | |
|---|---|---|---|---|---|---|---|---|---|
◆テスト自動化を始める前に、アジャイル・DevOpsチームが考えるべきこととは？ アジャイルテスティングの実現に向けた分析と戦略
https://codezine.jp/article/detail/14883?mode=print
２．テストの範囲＆観点
テスト範囲
- 構成要素(html/scss/ts、Presentation/Logic分離)
- Model
- Component(Page)
- Service
- IF(API)
- UI(DOM)
テスト観点
- 意図しない見た目の変更が発生していないかを検知
- ロジックが正しいことの確認
- ユーザ操作による挙動の確認
・表示（template部分）に関するテスト
・各コンポーネント内のイベントやロジックに関するテスト
・コンポーネント間に跨る挙動に関するテスト
このうち上２つは各コンポーネント毎、最後は各ページ毎に考えます。
テスタビリティの品質モデル
| 指標 | 概要 |
|---|---|
| 実行円滑性 （Operability） |
テストを円滑に実行できるかどうかを測る指標です。 例えば、テスト実行中にテストを妨げるようなバグが発生しにくいことなどが挙げられます。 |
| 観測容易性 （Observability） |
テスト対象の出力内容や発生するエラー・不具合を確認しやすいかどうかを測る指標です。 例えば、エラー発生時にテスト実行者がそのエラーを検知しやすいことや、システムの内部ステータスを外部から取得する手段があることなどが挙げられます。 |
| 制御容易性 （Controllability） |
テストを行う際の操作や制御がしやすいかどうかを測る指標です。 例えば、テスト対象の内部ステータスをテスト内容に合わせて操作可能であることなどが挙げられます。 |
| 分解容易性 （Decomposability） |
テスト対象のシステムに関して、テスト対象とする範囲やテストを実行する範囲を分離しやすいかどうかを測る指標です。 例えば、テスト対象が依存するコンポーネントをスタブやモックによって置き換えが可能であることが挙げられます。 |
| 単純性 （Simplicity） |
テスト対象のコードの構成や機能仕様のシンプルさを測る指標です。 例えば、不要な処理の呼び出しや冗長なコード構成になっていないことが挙げられます。 |
| 安定性 （Stability） |
テストの設計・実行負担を増やすようなシステムの変更が少ないかどうかを測る指標です。 例えば、インターフェースの仕様変更が少ないことや設計方針の転換が起こりにくいこと、発生したとしてもテストの設計内容を修正するコストが低いことなどが挙げられます。 |
| 理解容易性 （Understandability） |
テストを設計するにあたって、必要なテスト対象の情報を引き出しやすいかを測る指標です。 例えば、内部構造を熟知せずともAPI仕様などの情報を理解しやすいことが挙げられます。 |
◆テスタビリティ（テスト容易性）への投資は生産性向上につながる
https://www.qbook.jp/column/753.html
３．テストの種類
| No | テスト | 概要 | ツール例 | メリット | デメリット |
|---|---|---|---|---|---|
| 1 | 静的テスト | eslint 等を使った静的解析や、TypeScript 等を使った静的型チェック、typo チェックなど。 構文エラーだけでなく、書式の規則もやっておいたほうがよいかも |
ESLint Stylelint Prettier |
||
| 2 | 単体テスト | 最小単位の関数やコンポーネントのテスト | Jasmine+Karma | ||
| 3 | 結合テスト | コンポーネント、hooks を組み合わせて正しく動作するかをテスト | Testing Library | ||
| 4 | UI(E2E)テスト | 何をすべきか、およびどのような結果が期待されているかに関して、プログラムに指示を出し、実際のブラウザでのユーザーとの間のインタラクションをテスト | Selenium | ||
| 5 | スナップショットテスト | あるプログラムの出力を以前の出力と比較し、両者に差分があるかをテストする手法 | Jest | ||
| 6 | ビジュアルリグレッションテスト(VRT) | 変更前のWebサイトのスクリーンショットを用意しておき、変更後のスクリーンショットを撮り比較することで、どこが変わったか差分を表示し確認 | Playweight＋reg-suit | ||
| 7 | クロスブラウザテスト | ブラウザ・OSの組み合わせを変えたとしてもちゃんと動くかの検証 | ？ | ||
| 8 | アクセシビリティテスト パフォーマンステスト |
非機能テストのうち、心身特性に隔てのない製品を提供できているかという検証 アプリケーションのパフォーマンスと安定性をテストする |
Lighthouse | ・簡単にチェック可能 |
※新規で作成する場合と既存テストの拡張で対応方針は異なる認識
【メリット・デメリットの観点】
・学習コスト(＝導入含む)
・実装コスト
・実行速度(=実行時間コスト)
・実際の差分(テスト/ブラウザ)
【良いテストの条件って】
・退行に対する保護
・リファクタリングへの耐性
・迅速なフィードバック
・保守のしやすさ
【テストバランスと重要度のマトリクス-format】
| テスト種類 | 重要度3 | 重要度2 | 重要度1 |
|---|---|---|---|
| 静的(?pt) | |||
| 単体(?pt) | |||
| 結合(?pt) | |||
| UI(?pt) | |||
| SS(?pt) | |||
| VRT(?pt) | |||
| A,P(?pt) |
◆フロントエンドの"ちょうどいい"自動テストのはじめかた - Atrae Tech Blog
https://atraetech.hatenablog.com/entry/2022/09/30/105747
参考サイト
◆フロントエンドのテスト手法、何がある？ 知っておきたいテストとその戦略を網羅的に解説
https://codezine.jp/article/detail/17672
※このサイトで概要を把握するとよいかも...
◆あなたはフロントエンドの何をテストしたいのか。
https://qiita.com/kotauchisunsun/items/066f1df8a6179907d1fd
※同じことをやろうとしているので、その考え方を参考に...
◆テストから逃げてきた人が考えるフロントエンドテスト戦略についての考察｜株式会社コアテック
https://core-tech.jp/blog/tech_log/3292/
※下記目次レベルで考える！！
・なぜテストを行うのか
・テストを行うことによるメリット/デメリット
・何をテストするのか
・どうやってテストするのか
・どこまでテストするのか
◆【入門】フロントエンドのテスト手法まとめ
https://qiita.com/KNR109/items/7cf6b24bed318dab5715
★後で内容を理解して整理！！
◆フロントエンドのテスト戦略について考える
https://zenn.dev/koki_tech/articles/a96e58695540a7
◆フロントエンドのテストの種類多すぎ問題を整理する
https://blog.owlcode.net/posts/20211114-front-test
※Testing Trophy/テストの分類＆手法⇒後で整理
◆フロントエンドにおける「単体テストの考え方/使い方」
https://zenn.dev/akfm/articles/frontend-unit-testing
※良い単体テストとは
・退行に対する保護
・リファクタリングへの耐性
・迅速なフィードバック
・保守のしやすさ
◆フロントエンド:単体テストの観点
https://zenn.dev/shunshimono/articles/2023-04-10_test
※「まず初めに各種テストの説明」
◆フロントエンドのテストに真面目に向き合う
https://qiita.com/okmttdhr/items/cc58e83c259aa0049538
※仮想DOMと実DOMの話は後で確認！！
◆フロントエンドのテストについて
https://qiita.com/koda-momo/items/7373340dfc40030a79b7
※後で参考サイトの情報等を見てみる
◆Webフロントエンド再設計: レイヤードアーキテクチャの導入 ~ 高品質なコードを実現するために ~
https://zenn.dev/moneyforward/articles/e97dd1c0412071
※「テスト」や「ドキュメント」の箇所は後で参考に
◆フロントエンドのテストを書く時に私が考えていること
https://dev.classmethod.jp/articles/how-to-unit-test-frontend/
※テスト観点
・表示（template部分）に関するテスト
・各コンポーネント内のイベントやロジックに関するテスト
・コンポーネント間に跨る挙動に関するテスト
このうち上２つは各コンポーネント毎、最後は各ページ毎に考えます。
◆フロントエンドの単体テストってなんだ・・・？
https://dev.classmethod.jp/articles/what-is-frontend-unit-test/
※SPAでの単体テスト
フロントエンドの単体テストで主に確認すべきことは、データ（JSON等）を受け取ったときに想定通りの表示・挙動がされるかどうか、各種イベント発火時に想定通りの挙動をするかどうか（他にもあるかも）かと考えます。
◆フロントエンドのテストコードを書くときに大切にしていること
https://blog.cybozu.io/entry/2022/11/14/120000
※色々刺さることが書かれている...「テストコード上のロジックを避ける」自分なら、きっと普通に書いちゃってるー
◆フロントエンドのテストは皆のためのもの
https://postd.cc/frontend-testing-is-for-everyone/
◆フロントエンドの単体テストの使い方/考え方
https://speakerdeck.com/tnyo43/kao-efang
◆フロントエンドの単体テストで実感したメリット
https://tech.i3-systems.com/entry/2022/12/15/110217
※メリット
リファクタリングがやりやすくなる
実装のミスに早く気づける
共通コンポーネントの仕様変更が行いやすくなる
◆メルペイフロントエンドのテスト自動化方針
https://engineering.mercari.com/blog/entry/20211208-test-automation-policy-in-merpay-frontend/
◆実用的なフロントエンドのテスト戦略（1）
https://meetup-jp.toast.com/1550
◆実用的なフロントエンドのテスト戦略（2）
https://meetup-jp.toast.com/1757
◆実用的なフロントエンドのテスト戦略（3）
https://meetup-jp.toast.com/1771
◆ビジュアルリグレッションテストのすすめ
https://zenn.dev/roki_na/articles/6e17079d91f82f
◆【Angular】mswで簡単APIモック
https://qiita.com/nishitaku/items/cd8991ce3eede6728c19
※msw⇒Mock Service Worker
◆Angular Service Workerを導入する
https://qiita.com/massa142/items/339929ae56de88c8f451
◆Angular アプリケーションに Testing Library を導入する
https://kasaharu.hatenablog.com/entry/20221201/1669846855
★結合テストやTesting Libraryって何をイメージする際に...
◆testing-library でユーザの気持ちになって書くフロントエンドのテスト
https://zenn.dev/tnyo43/articles/39e4caa321d0aa
◆Webサイトリリース前に確認すべきSEO内部施策10項目をご紹介！ | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
https://liginc.co.jp/561047
◆GitHub - perjerz/lighthouse-ci-angular
https://github.com/perjerz/lighthouse-ci-angular
◆GoogleによるWebサイトパフォーマンス測定ツール「Lighthouse」入門
https://knowledge.sakura.ad.jp/21477/
◆Lighthouseの計測結果を見ていく
https://qiita.com/nightyknite/items/22d9f818dbab9bf171a3
◆Google Lighthouseでエラー
https://www.omakase.net/blog/2022/10/google-lighthouse-1.html
※もしエラーになったら、このオプションを試す
◆UIコンポーネントだけじゃないスナップショットテストの使い所
https://zenn.dev/loglass/articles/595a91af94ff27
※すごくわかりやすい！！
◆スナップショットテストの向き不向きについて考えてみる
https://www.mizdra.net/entry/2021/02/04/003728
※向き不向きについて詳しく書かれている！！
◆Angular: Angular CLI の Jest サポートを試す
https://zenn.dev/lacolaco/articles/angular-16-jest
◆Angular13でJestを導入してみる
https://qiita.com/neocoronb/items/7619064b52de3673239b
◆AngularプロジェクトへJestを導入する
https://blog.lacolaco.net/2021/06/angular-jest-setup/
◆Angular テストフレームワーク を jasmine/karma から Jest に移行しました
https://kakehashi-dev.hatenablog.com/entry/2022/07/06/090000
※移行する際はすごく参考になりそう！！
◆Snapshot Testing
https://runebook.dev/ja/docs/jest/snapshot-testing
★スナップショットテストって何をイメージする際に...
◆CSSのテスト | 前編 何をテストするのか
https://www.codegrid.net/articles/2015-css-testing-1/
◆Angular でアプリケーションを作成したらやること 4 点
https://qiita.com/kasaharu/items/abfa04dd5d461c67ab38
※stylelintを導入するのか...