Zenn
Closed10

Web系のイベント参加記録

イベントレポート
nori0__nori0__

こういうイベントの話はどこにかくのが良いのかねぇと思いながらここにかく

nori0__nori0__

LT&ディスカッション5ラウンド！うひょさん・よしこさんと改めて考えるReactコンポーネント設計

LT&ディスカッション5ラウンド！うひょさん・よしこさんと改めて考えるReactコンポーネント設計 - connpass
LT&ディスカッション5ラウンド！うひょさん・よしこさんと改めて考えるReactコンポーネント設計 - Speaker Deck

分割粒度

  • よしこさん
  • うひょさん
    • 1ロジック1コンポーネント
    • UIコンポーネントは共通化されたデザインのみ発生する印象。modelとUIがきちんと分かれていない
  • 2人ともSPAでNext.js
    • ルーティングをクライアントでする
    • クライアントでデータを取得する
  • SSRは作っているものがmediaを使ってないのでメリットが薄い。SSRがだと複雑になる傾向

構造

  • よしこさん
    • レイヤー間の依存ルールと強制
    • 外部ライブラリに依存する際のhooks化
  • うひょさん
  • Reactでロジックを書かずRecoilなどでロジックを閉じる

スタイリング

  • 2人ともcss modulesが好き
    • 最新のCSSをキャッチできるのが良いとのこと
  • 暗黙の依存関係を避ける
    • マージンを持ったコンポーネント、ダメ絶対。親子コンポーネントが依存している状態になってしまう
    • display: flex;とflex: 1;などセットのスタイルは同じコンポーネントが持つべき

テスト

  • UIのデグレ防止のためVRTに力をいれている
  • DOMのスナップショットは実装していない
    • よしこさん曰く今までDOMのスナップショットで助かった記憶がないとのこと
  • フックに対するUTが重要
    • ロジックに対するテストの重要度が高い
    • UIの挙動を見るなら実際にブラウザを動かした方が価値が高いと考えているそう
      • 例えばイベント実行でのRTLはブラウザと完全にイコールではなく価値が薄くなるため実際にブラウザを動かした方が価値が高いのではとのこと

パフォーマンス

感想

  • UIの評価はVRTにお任せするのが良さそう
  • テストの価値は今までテストを動かして助かったかどうかで判断するのは良さそう
    • 体感、VRTやロジックのUTは事前にバグやデグレを発見できているのでそれらを優先したい
  • ルールと呼ばれるものはlintなどでエラー出させたりしてさせるのはやっぱりいいよね、意識的に気を付けるようにチームで伝えるよりautofixできたり検知できる仕組みづくりが大事だなあと思った
nori0__nori0__

チームでのアクション

  • DOMのスナップショットは削除した
    • メンバーにも聞いたが助かった記憶がないという話になった
    • 微々たるものだがメンテコスト削減につながった
  • VRTを増やしたいと伝えてみる予定
    • UIのデグレちょこちょこ起こっているため
  • ロジックをhooksに出すのは意識してやっていきたい
  • スタイリングに関する話はリファクタしないと手をつけられそうにないのでリファクタの機会を窺う。様子見
nori0__nori0__

takepepeさんと振り返る　フロントエンドの書くべきだったテスト、書かなくてよかったテスト

takepepeさんと振り返る　フロントエンドの書くべきだったテスト、書かなくてよかったテスト - connpass

  • テストに期待すること
    • バグやインシデントを防ぎ、品質を高める
    • →根拠のある自動テストは自信と安心に繋がる
    • そのためにテストの目的の解像度をあげる必要がある
nori0__nori0__

書くべきだったテスト

  • Routerに関する評価観点
    • 特に「Linkコンポーネントの繊維先」「Routerに関する処理」を厚めに書きたい
    • どうあってほしいかをテストコードで表明する
      • 例えばSerchParameterのstring[]をどう処理するか？
  • 要素が複雑な機能のテスト観点
    • 関数Aを修正したらAの参照先の関数Cがリグレするパターン
    • 参照先も含めて評価しておければ後任エンジニアも安心して改修できる
  • コンポーネントのテスト
    • ロジックを単体でしっかり評価
    • コンポーネントテストは薄めに評価
  • セマンティクスやキーボード操作の不備に気づく
  • 共通UIコンポーネントのテスト観点
    • VRTが主流
    • リファクタリングが安心して行えるように

書かなくてよかったテスト

  • ブラウザの自動テストがFlakyになってしまった
    • テスト技法の得手不得手を把握して、肥大化しすぎないようにする
    • 安定＊忠実＝信頼されるテスト
      • 忠実性: 実際ユーザーが使用する環境に近いかどうか。ブラウザ評価は高いがエミュレーターを使うと低くなる
  • 書かれることが目的のテスト
    • Mockばかりのテスト
    • 他の評価と量を揃えたいだけに書いたテスト
    • テスト観点がなく目的がないなら書かなくてよい
  • 無理にariaを付け足したテスト
    • data-test-id をつかう
  • 過剰なVRT
    • ビジュアルリグレッションが発生するケースを想定して実装
    • 他のテスト技法によって担保されているなら書かなくてよい
nori0__nori0__

VRTに関して

  • VRTの範囲は？
    • atomic designでいうOrganismsやPageなどの共通コンポーネントを使用しているコンポーネント
  • VRTが不要な場合とは？
    • あまりない。ただし新規に立ち上げたばかりのプロジェクトはまだデザインが定まっていないので定まってからの方がよい
    • storybookのバージョンをあげた時は壊れやすいため判断が必要

コンポーネントテストに関して

  • コンポーネントテストが必要？
    • 機能を確認するテストにする方がよい
      • 例えばインタラクト(ボタンを押下して機能が動くなど)辺りを確認するなど
        ただしVRTが実装済みならインタラクトに関するコンポーネントテストは不要と思われる
  • UTはカスタムフック？コンポーネントテスト？どちらで担保するのがよいか？
    • 実行時間が短いのでカスタムフックがよい。
    • テストがないときはコンポーネントテストとして外から評価するリグレッションテストにするのがよい
  • VRTは忠実性は高いがコンポーネントテストは忠実性は低い
  • まずは小さく実装するのがよい

CIに関して

  • CIに時間が掛かる問題
    • 時間差でCIを実行する
    • アニメーションなど閾値をあげるようなテストを外す

テスト実装に関して

  • テストを書くタイミング？
    • VRTはUIができあがったあとがよい
    • ロジックのテストは実装と一緒に(同じ人が)実装するのがよい
  • テスト実装の優先度は？
      1. E2E (外から)
      1. UT (中規模)
  • 共通メソッドをつかう箇所の評価は？
    • 分岐をしっかり評価する、ホワイトボックステストにするのがよい
  • E2E->UTにする判断は？
    • DBが必要
    • ブラウザ間の画面遷移がある
  • テスト観点はどこか？が大事
  • Test toolの得手不得手から考える
  • (個人的に耳たこだが)テスト書きにくい＝設計を見直すチャンス

感想

  • Testing Trophyを目指しつつテスト技法を使い分けることが大切
  • テストの目的を忘れて脳死で実装してもメンテが大変などいいことがないので気を付ける
nori0__nori0__

テスト自動化実践ガイド ー 継続的にWebアプリケーションを改善するための知識と技法 - FL#65

テスト自動化実践ガイド ー 継続的にWebアプリケーションを改善するための知識と技法 - FL#65 - connpass

  • アジャイルテストの４象限
  • リソースの問題で一定期間ごとにテストする、ハッピーパスだけのテストにするなどするためにネゴシエーションするといったことが起こる
  • 開発サイクルとリリースサイクルは異なる
    • リグレッションテストがリリースサイクルにあっても開発は早くならない
    • 開発サイクルの中に入れないと気づくタイミングが遅れるだけ
  • E2Eテストの良い点を理解した上でテストする項目を考える
    • ブラウザデバイスの互換性テスト
    • 仕様化テスト
    • 生きたドキュメント(最新の仕様として使える)
    • 監視 (ログインできるかを定期的に実行して監視)
    • 意味のあるまとまりでテスト可能 (登録機能だけ、登録から購入までビジネスプロセス一連)
nori0__nori0__

質疑応答

  • OSSより有料のAutifyなどを使った方がサポートを受けられるため良い
  • テストピラミットのうちのどれを選択すべきかの判断は？
    • テストピラミットは一般的にE2Eで実現できないものをUTで担保するなどがあるためこのバランスになるだろうというもの
    • テストピラミットは十分なテストを書いているか？は不十分。カバレッジを見るべき
    • 仕様のうちのどれだけカバーしているかもカバレッジに当たる
    • 単体テスト自体が間違っておりレビューやテストでバグに気付けず本番でエラーが発生する場合
      • 単体テストのコードレビューをちゃんとする
      • どんなテストでも通るようになってしまっていないか？一度わざと間違って失敗しているかチェックするのも有用
  • 手動テストからリグレッションテストに置き換える時優先すべきテストは？
    • クリティカルユーザージャーニーを重点的に実施すべき
    • テスト実現性より重要なテストを選ぶこと
  • テストコードのレビューが十分にできないのはチームの問題。属人化しないように全員レビューに参加するのが大事
  • Gherkin記法
nori0__nori0__

今後は Github 管理できる article の方で記載していく

このスクラップは2ヶ月前にクローズされました