4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

フロントエンドのテストについて

Last updated at Posted at 2022-06-10

■はじめに

私は現在フロントエンドエンジニアとしてJestを学習しているのですが、そもそもテストについての根本知識が0であり、どのようにテストを進めていけば良いのか分かりませんでした。
そこで今回は「そもそもフロントエンドのテストとは何ぞや」という事について私がサイトを漁って取得した情報をまとめたいと思います。

※テストについてはプロジェクトや個人によって意見が異なる部分があるため、あくまでも参考程度にご覧ください。

■テストを何故行うのか?

ソフトウェアが正しく動作する事を保証する、信頼を上げる目的で書く

カバレッジ率や品質を上げる事が目的ではない

■フロントエンドのテストの種類

◎静的テスト(Statictテスト)

typo チェックや型チェック等、コード作成中に行う
ツール:eslint、prettier等

◎単体テスト(Unitテスト)

最小単位のメソッド、コンポーネントのテスト
ツール:Jest、Mocha等
対象 :詳細設計

◎結合テスト(Integrationテスト)

複数のメソッド、コンポーネントを繋げてテスト
ツール:Jest、AVA、Testing Library、Enzyme
対象 :基本設計

◎End to Endテスト(E2E,UIテスト)

・ユーザの動作を想定しながら実際に画面を操作して行う
・シナリオ(動作の流れ)を基にテスト
・動作前後でスナップショットを撮り、保存しておくのがおススメ(後で確認しやすい)

ツール:Cypress等
対象 :要件定義、ユースケース


それぞれの区別は、買い物サイトで例えるなら下記のイメージ…?
image.png


◎目線での分類

・ホワイトボックステスト
 →コードの内容を知った上でテスト=エンジニア目線
   静的テスト~結合テスト

・ブラックボックステスト
 →コードの内容が分からない状態でテスト=ユーザ目線
   E2Eテスト

◎手法での分類

・リグレッションテスト
 →コードになんらかの変更を行った後に動作が担保されているかを確認するために実行

・スナップショットテスト,ビジュアルリグレッションテスト
 →動作前後画面を比較、見た目が大きく変わっていないかをテスト

■どのタイミングでテストをする?

実装の前

TDD(Test Driven Development:テスト駆動開発)
実装する前にテストコードを書く→それに合わせて実装
テストに通るようなコードを書いていく手法

◎BDD(Behavior Driven Development:振る舞い駆動開発)
TDDとほぼ同じだが、具体的やり方テンプレート?があるので少し進めるのが楽

実装中

これは後述でのCI/CDでの開発にあたると考えられる。

実装の後

設計→実装→設計を基にテスト

■テストを行う際に意識すること

・結合テストを手厚く
→Kent C. Dodds氏が述べている記事から、結合テストは「工数」「コスト」「保証」のバランスが一番良いため。
また結合テストを行えば単体テストの部分はある程度網羅出来、逆にE2Eでは範囲が大きすぎてバグに気が付かないため結合テストの立ち位置が丁度良いのではないかと考えられる。

・なぜそこをテストするのか?を明確に
→無駄なテストは行わない。

・単体テスト、結合テストではAPI等外部システムは使わず、モックしてテストする
→原因がAPIにある可能性もあり、純粋なフロントのテストにならないため

■テストの粒度

ではどのレベルでテストを行えば良いのか?

◎単体テスト
バグが起こったらまずいところを重点的にテストする
→具体的にはアクセス集中ゾーン、課金ゾーン等

◎結合テスト
全体的に網羅することを目指す。
しかしカバレッジ率を上げる事が真の目的ではないので、あくまでも「テストの意味がある範囲で」100%を目指す。
モックはなるべく少なく、早く回せるように意識

■おまけ:最近よく聞くCI/CDとは何ぞや

GitHub等にコミットするとその都度自動でテストを回してくれる
→問題なければマージ、デプロイされる

◎メリット
・アジャイル開発にとても良い
・環境に左右されないテストが出来る

◎デメリット
・コミットとマージの間が少し空く→コミットをこまめにして変更部分を少なくする

◎主なツール
オンプレミス型:Jenkins
クラウド型:Travis CI、CircleCI

■まとめ

とりあえず下記を意識しておけば問題なさそうです。

・テストは結合テストに重きを置く(全体的に網羅する)
・外部のシステムは使わずにモックして行う
・単体テストは重要だと考えられるメソッドのみで行う
・カバレッジ率よりも「そのメソッドに対してテストをする意味」を大事にする
・テストを行うタイミングはプロジェクトによる

テストはかなり奥が深く、正解を突き詰めるときりがなさそうな印象でした。
そもそもフロントのテストは時間や工数的に全て行う事が不可能なため、どこまでやるかの定義が難しくなってしまうのですね。。

ここまでご覧頂きありがとうございました。

■参考URL

4
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?