Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MeetUP2_フロントエンド結合テスト_20220419

 MeetUP2_フロントエンド結合テスト_20220419

89d1ae72e8683e44c744f4cab8d99f39?s=128

BrainPad

May 31, 2022
Tweet

More Decks by BrainPad

Other Decks in Programming

Transcript

  1. 株式会社ブレインパッド 田中 康平 2022年4月19日 フロントエンドのテスト方針と結合テストのすすめ

  2. ©BrainPad Inc. Strictly Confidential 自己紹介 | 田中 康平 2 所属

    • 株式会社ブレインパッド プロダクトビジネス本部 開発部 趣味 • キャンプ • サウナ • Mリーグ • メディアアート
  3. ©BrainPad Inc. Strictly Confidential フロントエンドに関する • チームで運用しているテスト方針について • 結合テストについて ◦

    実際の取り組み事例、結合テストの効果 ◦ 運用している結合テストのガイドライン ◦ 運用上得られたTipsや、苦労したこと 注記 - ここでは複数のモジュールを組み合わせたものを結合テストと呼びます - フレームワークはVue.jsを採用 本日お話すること 3
  4. ©BrainPad Inc. Strictly Confidential さまざまなデータを活用する Web・アプリのコンテンツ最適化プラットフォーム 多彩なパーソナライズやレコメンドで顧客一人ひとりに自然なアクションを促します Rtoaster action+ とは

    4
  5. ©BrainPad Inc. Strictly Confidential 350社以上の導入実績 Rtoaster action+ とは 5

  6. ©BrainPad Inc. Strictly Confidential 技術スタック • Vue.js(v2), Nuxt, TypeScript, composition-api

    • Riot.js(v3), jQuery, JavaScript 状況 • Riot.js -> Vue.js フレームワーク絶賛移行中 今回は移行中の Vue で新たに策定したテスト方針についてお話します。 Rtoaster action+ の技術スタック と 状況 6
  7. ©BrainPad Inc. Strictly Confidential • 品質を高めるための 1つの手段 • こちらの意図通りにユーザーがサイトを閲覧し、サイト上で機能を使用できるかを検証するもの •

    開発の可能な限り早い段階でエラーを発見するためのもの フロントエンドのテスト目的 7
  8. ©BrainPad Inc. Strictly Confidential テストの種類 / 用語 8 種類 説明

    ツール 静的解析(Static) 型や Lint などの静的なチェック TypeScript, ESLint 単体テスト(Unit) 個々のコンポーネントや関数などを個別に検証する テスト Jest, vue/test-utils 結合テスト(Integration) コンポーネント間、ページ単位など複数の要素の相 互作用を検証するテスト Jest, vue/test-utils Vue Testing Library E2Eテスト(End to End) アプリケーション全体をブラウザ環境で検証するテ スト TestCafe , Cypress
  9. ©BrainPad Inc. Strictly Confidential どのテストにどれだけコストを使うべきかをトロフィーの体積 で示している。 「結合テスト > 静的解析 >

    単体テスト > E2Eテスト」 となって いる状態がコストパフォーマンスのバランスが取れた理想 状態である Testing Trophy 9 https://testingjavascript.com/
  10. ©BrainPad Inc. Strictly Confidential 内部実装を変更するとき、壊れてはいけない 小さなリファクタリングのテストで壊れてしまうと、コードを改善するときに信用できなくなる。また、テストを修正するためのコストが 発生し、コードの改善を妨げることになる。実装ではなく振る舞いのテストを行うことが重要 バグを検出できなければならない テストが期待する結果を具体的に明示しなかったり、または予測可能なシナリオをすべて検証しなければ、製品コードにあるバグを 発見できないことがある。また、モックオブジェクト(Mock)を過度に使用すると、依存性のあるオブジェクトの動作が変わっても、テ

    ストコードが接続過程でバグを全く検出できなくなる。したがって、テスト仕様は具体的でなければならず、モックオブジェクトの使用 は可能な限り控えることが重要 良いテストの条件 10
  11. ©BrainPad Inc. Strictly Confidential • 実装ではなく振る舞いのテストを書く ◦ 内部実装を変更するとき壊れないテストにする • バグを検出できるテストを書く

    ◦ テストケース、テストが期待する結果を具体的に明示する ◦ 予測可能なシナリオを限りなく検証できるようにする • 結合テストを最も多く書く ◦ ここでは複数のモジュールを組み合わせた単体テストを統合テストと呼ぶ ◦ モックオブジェクトを多用し、実装の検証となるような単体テストは書かないようにする ◦ 結合テストでモジュール間の相互作用を確認することでバグを検出できるようにする action+ フロントエンドのテスト方針 11
  12. ©BrainPad Inc. Strictly Confidential 機能 • データの一覧取得・表示 • データの編集・取り消し etc

    • データの新規作成 • etc 実際の取り組み 結合テストの効果 12 実装 • 各components(grid、button、 bread-crumbs, icon, popup, etc) • 各services(api, auth, i18n, etc ) • 各 utils (date, escape, etc) 関連するファイルは 60以上
  13. ©BrainPad Inc. Strictly Confidential テスト方針に沿ったテストと テストケースのサンプル 実際の取り組み 結合テストの効果 13

  14. ©BrainPad Inc. Strictly Confidential 以下7つのテストケースを実行 実際の取り組み 結合テストの効果 14

  15. ©BrainPad Inc. Strictly Confidential 結合テスト実行結果 15

  16. ©BrainPad Inc. Strictly Confidential 結合テスト実行結果 16 今回の例では、僅か 7つのテストケースで 振る舞いに使用される components,

    services, utilsの相互作用(60 ファイル以上)を検証することができる 内部実装が変更になっても振る舞いが変わらないければこのテストは壊れないようになっている
  17. ©BrainPad Inc. Strictly Confidential • mock, stubsを利用して良い箇所をガイドライン化 ◦ mockを極力減らしモジュール間の相互作用を確認す ることを実現

    ◦ 具体的には api response、$router や $route、 stubs はnuxt-child, nuxt-link, portal-target 以外の使用はNG としている • i18nの対応 ◦ CustomFormatter 、リスト補間 {0} も表示可能とし、 productionと同じ動作ができるようにした • クリックの振る舞いを検証する際のselectorのガイドライン化 ◦ デザインに依存しないテスト ◦ data-testidの付与 compnent名-hoge テスト方針を実現するために工夫、苦労した(している)ところ 17
  18. ©BrainPad Inc. Strictly Confidential • pluginで context に inject した関数や値の対応

    ◦ testで動作できるよう に$nuxt.context の mocksに該 当コードを注入 • layout/default.vue に依存している箇所の対応 ◦ default.vueで使用しているコンポーネントが 各 page の結合テストで必要になる場合 ◦ wrapperを用意, loadingのflagなどは context mocks をハードコーディング • Jestのエラーがわかりにくい ◦ 慣れが必要.. • 予測可能なシナリオを検証できるようにする ◦ 工数が掛かるので効果が高いテストを絞るのが現実 的... テスト方針を実現するために工夫、苦労した(している)ところ 18
  19. ©BrainPad Inc. Strictly Confidential • テストの目的、種類、良いテストの条件 • action+で運用しているテスト方針の紹介 ◦ 実装ではなく振る舞いのテストを書く

    ◦ バグを検出できるテストを書く ◦ 結合テストを多く書く • 結合テストの事例紹介 ◦ mockの使用を極力減らすことで、モジュール間の相互作用 をテストすることができる ◦ 上記のテスト方針を実現するための工夫、苦労した点の紹介 品質を高めるための効率的なテスト手法の模索は続く ... まとめ 19
  20. 株式会社ブレインパッド 〒108-0071 東京都港区白金台3-2-10 白金台ビル3F TEL:03-6721-7002 FAX:03-6721-7010 www.brainpad.co.jp info@brainpad.co.jp 本資料は、未刊行文書として日本及び各国の著作権法に基づき保護されております。本資料には、株式会社ブレインパッド所有の特定情報が含まれて おり、これら情報に基づく本資料の内容は、御社以外の第三者に開示されること、また、本資料を評価する以外の目的で、その一部または全文を複製、 使用、公開することは、禁止されています。また、株式会社ブレインパッドによる書面での許可なく、それら情報の一部または全文を使用または公開する ことは、いかなる場合も禁じられております。