journagu

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

目次

なにこれ

ここ 1、2 週間ほどテスト関連の話をよく聞いていて、そういえば Front-end ってどんなテストやっているのか全然知らなかったから調べてみた。

前提

  • フロントエンドのプロダクションコードを書いてない

モチベーション

  • フロントエンドのテストについて知りたい
  • 最近の動向を知りたい

テストの話

フロントエンドの単体テスト？

単体テストはアルゴリズムのロジックに対して行う時に有用。
→ 結合度の高いコードは結合テストをしっかりやるのが効果的。

密結合なものは結合テストをする。

https://postd.cc/a-response-to-why-most-unit-testing-is-waste/

単体テストが書けるような設計・実装をする

  • 例えばボタンを追加するとして、とりうる内部表現は無数にある
    • テスト対象の表現が一意に定まらない
  • 他の開発者のために自分が書いたコードが要求を満たしているか検知する手段としての単体テスト
  • GUI 開発は「ユーザがどう感じたか（UX）」に集約される
    • UX は単体テストの範疇外
  • 単体テストが書ける = 不要な依存がなくモジュール同士の境界面が自明になってる
    • 単体テストが書けるような設計を目指すとよい

https://mizchi.hatenablog.com/entry/2018/03/13/214755

UI 変更に耐えうるテストは難しい

フロントはロジックの変更よりも UI 変更の頻度の方が多い。
→ ボタンのデザインを変えたりするとテストのリファクタリングがはじまる

http://w3q.jp/t/9438

ビジュアル要素のテスト

  • スナップショットテスト（html / 仮想 DOM）
    • html の比較: 仮想 DOM→HTML→diff をとる
    • 仮想 DOM の比較: 仮想 DOM→diff をとる

内部実装を変更するとテストに通らなくなる & 見た目（ブラウザへの描画結果）のデグレがわからん

https://meetup-jp.toast.com/1550

まとめ

  • ロジックをできるかぎり切り出す
    • 切り出したロジックに対しては単体テストをする
  • デザイン崩れを検知するにはビジュアルリグレッションテスト
    • デザインを変更するとテストの修正も必要になるから程々に
    • デザイナが目で確認するのが良い

悩んだら読むと良さそうなサイト

ほいでは ٩( ᐛ )و