📗

フロントエンドテスト入門 〜テストの種類と目的〜

2023/10/05に公開

はじめに

専門学校に入学して約半年が経ちます....この10月から就活が始まり、色々と追われてきました。(時の流れは早い...)
先日、地元(神戸)のコミュニティのイベントに参加させていただき、テストに関する講演を聞く機会がありました。そこで、テストについての興味が湧いたので、フロントエンドにおけるテストに入門してみようと思います!

(参考書籍)
https://www.amazon.co.jp/フロントエンド開発のためのテスト入門-今からでも知っておきたい自動テスト戦略の必須知識-吉井-健文/dp/4798178187/ref=sr_1_2_sspa?adgrpid=151134669329&gclid=Cj0KCQjwmvSoBhDOARIsAK6aV7h_mkWfuVkX9sL6EGdAAViZYpveK6tCzlrSPImu2yLIFvAPnA1wS2IaApVyEALw_wcB&hvadid=656032414005&hvdev=c&hvlocphy=1009565&hvnetw=g&hvqmt=e&hvrand=13036909510486331498&hvtargid=kwd-2015117261656&hydadcr=3980_13317580&jp-ad-ap=0&keywords=フロントエンドテスト入門&qid=1696436845&sr=8-2-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1
この書籍を軸に、学んだことをアウトプットできればと思います💪

💫テストの種類(まとめ)

  • 単体テスト(UnitTest)
  • UIコンポーネント結合テスト
  • ビジュアルリグレッションテスト
  • E2Eテスト

単体テスト(UnitTest)

💡 単体テストを行うためには、ロジックとUIを切り分けないといけない(責務の分離)

「ロジックとビュー別のテスト」

  • 関数単体テスト:何かしらのロジック(機能)が正しく機能するかのテスト
  • UIコンポーネントテスト:データを受け取り、正しくUIを表示できるかのテスト
    関数(hooksなどのロジック)とUIコンポーネントに分けて単体テストを行う。
    SPABFFも複数の関数を組み合わせて構成することが基本
    Reactなど、関数で表現されるUIコンポーネントは単体テストと相性がいい

UIコンポーネント結合テスト

💡 UIコンポーネントの責務は、入力したデータを表示するだけではない!

「外部要因を含めたテスト」

  • 操作に応じた非同期処理
  • レスポンスに応じた表示結果の切り替え

ビジュアルリグレッションテスト

💡 大量のUIの変更を人力で追うのはBad...ツールを頼れ!

「見た目の比較を行うテスト」

変更前のスクショを用意しておき、変更後のスクショと比較することで、差分を確認する

https://zenn.dev/roki_na/articles/6e17079d91f82f

E2Eテスト

💡導入のコストとハードルは高い。方針を固めてチャレンジしよう!

「システム全体を通したテスト」

例:DBサーバーに接続したり、外部ストレージサーバーに接続する

  • ブラウザ固有のAPIの利用
  • 外部システムとの統合
  • 画面を跨ぐ機能

顧客視点からアプリケーションのワークフローを検証する
https://qiita.com/mt0m/items/7e18d8802843d9f60d28

💭テストを書く目的

  • 安全なプロダクトの納品
  • 長期的に保守・運用できるプロダクト管理
  • 業界の流れ

💡 テストを書く目的は、「テストを書いてよかった」という体験を通じて、初めて気づけるもの

✅テストを書く習慣を身につけ、些細なバグをなくそう!

事業の信頼のために

❌システムのバグはサービスのイメージに直結する

一時的にサービスが利用ができないという悪影響だけでは済まない

  • 大規模なサービスのシステムダウン→ネットニュース

最近はBFF開発を手掛けることも多くなった
→認証認可など、バグが含まれていては困るケースが増えてきている

健全なコードを維持するために

プロジェクトを進めるうちに、同じような実装箇所が出てくることはよくある...
->共通の処理はモジュールに切り出して共通化するなど、リファクタリングしたくなる場合がある

✅リファクタリングの際にテストがあると、既存の実装が壊れてないか確認できる!

テストが書けると、リファクタリングを行なった際に、テストを実行して既存の実装が壊れてないかを素早く確認することができる。

💡テストコードがあるという安心感は、積極的なリファクタリングを推し進め、健全なコードを維持してくれる

実装品質に自信を持つため

テストを書くということは、自身のコード品質を見直す機会ということ

テストコードが書きづらい=テスト対象に処理を詰め込みすぎている
-->機能の分割を行う

例:肥大化しすぎたUIコンポーネント

  • 表示分岐
  • 入力バリデーション
  • 非同期処理更新

これらの実装を一つのコンポーネントで実装してしまうと、困ってしまう

(...他にも、チームでのコラボレーションや、リグレッションを防ぐためなど色々と目的がある)

⏲テストを書くと節約できる時間

個人に焦点を当てると、テストコードを書く時間が増えるため、その分作業時間は増えるが...

チーム開発や、長期的なプロダクト制作に焦点を当てると、テストによって、「手戻り」や「リグレッション」がなくなり、その分の時間が節約できる

🧰テストツール

Jest

CLIベースのテスティングフレームワーク・テストランナー
Jest
https://typescriptbook.jp/tutorials/jest

Playwright

ヘッドレスブラウザを含んだテスティングフレームワーク・テストランナー

Fast and reliable end-to-end testing for modern web apps | Playwright
https://reffect.co.jp/html/playwright/

reg-suit

ビジュアルリグレッション/テスティングフレームワーク
reg-suit
https://zenn.dev/keita_hino/scraps/500f45bc926bc7

Storybook

UIコンポーネントエクスプローラー
Storybook: Frontend workshop for UI development
https://reffect.co.jp/html/storybook/

終わりに

テストの種類や、テストの目的、テストツールについてざっくりですがアウトプットしてみました。
基本的にはメモ感覚で書いているので、雑かもしれませんが、理解が深まったらまた綺麗にまとめようかなと思ってます✍️

「いいテストをかける人は、いいコードをかける人」 という言葉もあるそう(?)なので、綺麗なテストコードを書けるようになって、個人開発中のアプリにもテストを導入していきたいです。

入門したてですが、これからは実践も踏まえつつ、理解を深めていこうと思います🏃‍♂️

GitHubで編集を提案

Discussion