Zenn
Open21

フロントのテスト戦略！の知見が集まるところ

frontend
Test
ピン留めされたアイテム
seyaseya

なぜテスト戦略を策定したいのか
目的・課題感

seyaseya
  • フロントのテストはROIが読みづらいと思っている
    • バックエンドとかのユニットテストは動作確認の手軽な方法としても効果わかりやすいから、とりあえず全部ちゃんと書いておきましょうとやりやすいが、フロントはブラウザでサクッと見られるのと、見た目に関する assertion がプログラミングではむずいので難しい
  • なのでテストの粒度が個人の感覚ベースになってしまう。それはそれで正しい姿というかそうするしかないものかもしれないが、一度決まった指標みたいなのが言語化できないかを試みたい
seyaseya

成果物の定義

  • フロントエンドのベーシックな知識を持っているエンジニアが、自分が業務をしていく上で「ここはこういうテストを書いておかないとな」と迷いなく判断ができること。

  • フロントエンドのベーシックな知識のイメージ

    • コンポーネントベースでアプリケーション組んだことがある
    • 単体テストや Visual Regression Test の How についてはそんなに困ってない

あとテストできないのは単純にテストの書き方知らんだけみたいな話もありそうなので、めっちゃ詳細に色んなパターンのテストの書き方を集めるみたいなのも成果物の一つにはなるかも

seyaseya

バグはどんな時に起きるか

まずフロントエンドを作っていく上で起きるバグにどんなものがあるか分類を試みてみる

  • 考慮できなかった状態 → これはバグではないか
    • ある状態の時の表示をそもそも実装していない(empty, loading忘れたとか)
    • 考慮しきれなかった状態の組み合わせ
  • 副作用で不正な状態が作られてしまう
    • mutable な操作をしてしまう
  • Viewが変
    • コンポーネントをアップデートしたら、他の場所でデザインが崩れてしまった
    • モーダル消し忘れて

フロントエンドのバグ = 不正な状態を産んでしまうこと & 見た目のデグレを指すのではなかろうか。

seyaseya

ここからざっくり次のあたりが求めているものなんじゃないかという気がする

  • ロジックがある・まあまあ複雑なコンポーネント、hooks、state を変換するところ(redux 使っているなら reducer とか)の単体テスト
  • 見た目のデグレ検知 - Visual Regression Test
    • ここでいう "見た目" は DOM としての表現とかではなく、実際にブラウザに描画されたときの見た目なので、コンポーネントのユニットテストとかスナップショットテストは違う気がしてる
    • コンポーネント単体というよりは実際の画面上で動かした時が求めているところだから、E2Eを回すついでとかがベストか？
seyaseya

不正な状態を産んでしまうことを防ぐためのテスト

  • mutable な操作をなくす → テスト以前の話

    • 昔オブジェクトを参照渡ししてそれを直接いじっていた。表示のためにオブジェクトをいじってしまい、それが状態としての表現からズレてバグを多発させてしまった
    • 状態の操作を全て immutable にすることによって

  • コンポーネントの単体テスト

    • 想定される状態全ての掛け合わせでのテスト

  • アクションを引数に状態を変える関数のテスト

  • どんな時に状態が変わるか

    • Form
    • mutation、APIに write 系のリクエストを行う
    • ページ遷移をする
    • lifecycleのテスト
      • → 表示のために必要なデータを取るアクションをdispatchするくらいだから得られる安心感は低い

  • 状態とは何か

    • 外部のState
seyaseya

フロントエンドのコードを書いたあと何が壊れていないことを確認したいのか

  • 見た目の話
    • デザイン通りの見た目になっていること
      • 100% 一緒になっている必要はない & デザイナーも実際に動く画面で見たら変えたくなる時があるので人力でデザインレビュー
    • 見た目が変になる状態がないか
seyaseya

Howの話

seyaseya

jest

  • GitHub - facebook/jest: Delightful JavaScript Testing.
  • テストランナー
    • コマンドでテストを走らせたり
    • describe, it などの関数でテストケースを管理しやすくしたり、エラーがどこにあるか分かりやすくしたり
    • setup, teardown → afterAll, afterEach, before とか
  • expect などでテストの結果を判定するための utility を提供したりする(assertion)
  • Mock
  • snapshot

https://qiita.com/s_karuta/items/ee211251d944e72b2517

seyaseya

テストの難易度

  • インタラクションの難易度
    • フォームの入力やクリックは簡単
    • スクロール、d&d とかは難しい → 手動で諦めるポイント
seyaseya

知見集。
他の会社さんがどうやってやっているのか集めたい

seyaseya

Kent C.Dodds

JS テスト界の大御所。Testing Trophy の提唱者

テスト関連の記事のリスト
https://kentcdodds.com/testing/

Snapshot は Assertion と捉える
https://kentcdodds.com/blog/effective-snapshot-testing/?source=userActivityShare-7aad912c550f-1516512013

「何をテストしたらいいか」というドンピシャなタイトル

  • テストの目的
    • We write tests to be confident that our application will work when the user uses them
  • Think less about the code you are testing and more about the use cases that code supports.
  • どこが壊れたらビビるかを考える。優先度をつけてテストを書き始める
    • What part of this app would make me most upset if it were broken?
    • What would be the worst thing to break in this app?
    • 優先度をつけられたら E2E から書き始めるのがオススメ
    • E2Eではカバーしきれない(E2Eでカバーするのが割りに合わない)ものが出てきたら integration test を jest 使って書いていく

https://kentcdodds.com/blog/how-to-know-what-to-test