e2e_design.pdf

Transcript

1. E2E テスト設計 March 29, 2024 / 設計カンファレンス extends OOC @fumiyaki 設計カンファレンス extends OOC @fumiyaki 1
2. @fumiyaki 福岡県に住むフロントエンドが大好きなフロントエンジニア 趣味： ボルダリング，スノーボード，旅行，アニメ （注）x だけ@fumiyaki_です fumiya だと基本 username が取られているので ki をつけたのに， x.com だと既に取られていました(´；ω；｀) E2E テストを導入した時に考えた設計と実装と運用について | Offers Tech Blog https://zenn.dev/overflow_offers/articles/20231024design_impl_and_ops_guess_put_e2 e_test 設計カンファレンス extends OOC 自己紹介 2
3. はじめに 本日の発表内容は過去の経験から次に E2E テストを始める場合， どのように設計したら良いかを考えたものになります 時間をかけて改善された秘伝のタレではないことにご注意ください 設計カンファレンス extends OOC @fumiyaki 3
4. 前提 設計カンファレンス extends OOC @fumiyaki 4
5. 使用技術 Playwright 設計カンファレンス extends OOC 前提 5
6. フロントエンドとバックエンドの役割 設計カンファレンス extends OOC 前提 6
7. フロントエンドの役割 json 色付け a11y アクセシブルを保つためのバリデーション アクセシブルを保つためのエラーハンドル 設計カンファレンス extends OOC 前提 / フロントエンドとバックエンドの役割 7
8. フロントエンドの特徴 バックエンドから渡される複雑なデータをユーザーにとって理解出来る見た目に変換する コンポーネントの組み合わせによってユーザー体験を作る 1 つ 1 つの（UI としての）Component をテストするのは難しい 設計カンファレンス extends OOC 前提 / フロントエンドとバックエンドの役割 8
9. バックエンドの役割 ビジネスロジックの実装 認証認可 DB と通信 フロントとの窓口を作成 設計カンファレンス extends OOC 前提 / フロントエンドとバックエンドの役割 9
10. バックエンドの特徴 各種技術を組み合わせて機能を実現している 独立した技術要素を統合し、全体として機能するシステムを構築することが重要 1 つ 1 つの（機能としての）Component をテストするのは易しい 設計カンファレンス extends OOC 前提 / フロントエンドとバックエンドの役割 10
11. 前提のまとめ フロントエンドは組み合わせによって UI/UX が作られる バックエンドに比べてフロントエンドは単体で動作するものは多くない フロントエンドは単体テストし辛い バックエンドはビジネスロジックやビジネスドメインをコードで表現するためテストし易い →User ドメインクラスがあったとして username と password が必要で文字数制限などが正 しく効いているかをテスト出来る 設計カンファレンス extends OOC 前提 11
12. テスト戦略 設計カンファレンス extends OOC @fumiyaki 12
13. Testing Pyramid Testing Trophy 設計カンファレンス extends OOC テスト戦略 13
14. Testing Pyramid 設計カンファレンス extends OOC テスト戦略 14
16. 単体テストを厚く多く，E2E テストを最小限に留める バックエンドだと良い配分 フロントエンドでいう単体テストとは？ Button や Text などの atom レベルの Component をテストするのだろうか？ 複数の Component を使った Component は結合テストになるのだろうか？ hooks で切り出した関数のテストをしたら良いのか？ スナップショットテストや VRT を用いて TDD…？（いやそもそも変更検知用だし…） Testing Pyramid はフロントエンドだと良い戦略ではない 設計カンファレンス extends OOC テスト戦略 / Testing Pyramid 16
17. Testing Trophy 設計カンファレンス extends OOC テスト戦略 17
19. 型や Lint の恩恵を取り入れ，インテグレーションテストを厚めにした形 フロントエンドのために考案されたテスト戦略 設計カンファレンス extends OOC テスト戦略 / Testing Trophy 19
20. Testing Trophy の具体 設計カンファレンス extends OOC テスト戦略 20
21. 静的テスト 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 21
22. npm run build ESLint, Biome 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 静的テスト 22
23. npm run build 静的解析で壊れていないことを保証 目的 型的に問題のあるコードを混入させない 導入時期 プロジェクト初期 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 静的テスト 23
24. ESLint, Biome 潜在的な実行時エラーやアンチパターンを検出 目的 問題のあるコードを混入させない 導入時期 プロジェクト初期 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 静的テスト 24
25. 単体テスト 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 25
26. Snapshot test Visual regression test （hooks） 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 単体テスト 26
27. Snapshot test コンポーネントの構造やプロパティの変更を検知 意図しない変更・波及を検知 テストの実行が高速 目的 デグレ検知 導入時期 α バージョンリリース後 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 単体テスト 27
28. Visual regression test UI の見た目の変更を検知 意図しない変更・波及を検知 テストの実行が低速 目的 デグレ検知 導入時期 α バージョンリリース後 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 単体テスト 28
29. （hooks） Component のロジックをテスト可能 hooks 毎にテストを作っていたら大変なのでテストすべきかはしっかりと検討しましょう 目的 様々 導入時期 適宜 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 単体テスト 29
30. 結合テスト 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 30
31. Storybook Play Function(おすすめ) or React Testing Library storybook-addon-a11y 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 結合テスト 31
32. Storybook Play Function(おすすめ) or React Testing Library バリデーションが設定された Component で，エンドユーザーに操作ミスを伝えるメッセー ジが表示されるかをテスト 条件付きレンダリングをテスト 目的 条件付きレンダリング，バリデーション，エラーハンドルが正しく動作しているかを確認 導入時期 プロジェクト初期がベスト 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 結合テスト 32
33. storybook-addon-a11y Storybook 上でアクセシビリティに問題を検出 目的 a11y の問題を検出 導入時期 プロジェクト初期 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 / 結合テスト 33
34. E2E テスト ページを跨いだコンテキストを使った状態管理が正しいかをテスト 結合テストや単体テストでカバー出来ることを E2E テストでしない事が重要 目的 末端(DB や API)から末端(エンドユーザー)までを通して問題が無いかを確認 導入時期 α バージョンリリース後 設計カンファレンス extends OOC テスト戦略 / Testing Trophy の具体 34
35. テスト戦略まとめ フロントエンドでは Testing Pyramid より Testing Trophy が適している サービスを常に提供し続けるために，保守運用が楽なものは初期から導入して， α バージョンが完成後，適宜デグレを防ぐために対策を打っていく必要がある 設計カンファレンス extends OOC テスト戦略 35
36. E2E テストの設計 戦略的設計と戦術的設計 設計カンファレンス extends OOC E2E テストの設計 36
37. 戦略的設計 E2E テストで確認出来ること ユーザーストーリーを起点にする CI はススメではなくマスト 設計カンファレンス extends OOC @fumiyaki 37
38. E2E テストで確認出来ること アサーションを使って表示されているかの確認 掲示板に投稿したコメントが表示されているかをアサーションを使って検証する 一連の操作をシナリオを通してしてエラーを吐かずに完了するか ユーザー登録を進めていき，完了ページまで遷移出来るかを検証する 2 つの方法を使いながら E2E テストを作っていく 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 38
39. ユーザーストーリーを起点にする テストをしたくて疼いた時は焦らずに結合テストで実現できないかを考えましょう E2E テストはユーザーストーリー起点で始めましょう 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 39
40. ユーザーが絶対に体験するシナリオ 使用頻度の高いシナリオ ビジネス上重要なシナリオ 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 / ユーザーストーリーを起点にする 40
41. ユーザーが絶対に体験するシナリオ ユーザー登録 コンテンツの投稿から表示まで 友達・フォローの追加 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 / ユーザーストーリーを起点にする 41
42. 使用頻度の高いシナリオ Menu からの各ページ遷移が正しいか プロフィールの更新 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 / ユーザーストーリーを起点にする 42
43. ビジネス上重要なシナリオ 支払い アカウントの追加 退会処理 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 / ユーザーストーリーを起点にする 43
44. ユーザーストーリーを起点にするまとめ ここで提示したシナリオはよくあるサービスでの一例です サービス毎にシナリオの優先度は違うはずなので，PM と話すなどして重要なシナリオを発見 していきましょう 客観的な指標として Google Analytics のエンドユーザーのサイト内行動を見るのも良いと思 います 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 / ユーザーストーリーを起点にする 44
45. CI はススメではなくマスト 釈迦に説法だとは思いますが，テストは CI に載せて繰り返し動くようにしましょう Github Actions(CircleCi, Travis-CI, jenkins)を使って継続的インテグレーションをしましょう 設計カンファレンス extends OOC E2E テストの設計 / 戦略的設計 45
46. 戦術的設計 Page Locator Book のススメ 設計カンファレンス extends OOC E2E テストの設計 46
47. Page Locator Book のススメ ページ内の目当てまでの経路をページ毎に作成 メンバー変数はページが表示している Element までの経路を保持する 必要最低限のメンバー変数を実装する（頑張りすぎない） メソッドは実装しない メンバー変数名はページのどの部分を示すのか分かりやすく命名する header_menu_login_link main_contents_list_delete_button main_contents_card_add_button 設計カンファレンス extends OOC E2E テストの設計 / 戦術的設計 47
48. export class TopPageLocatorBook { private readonly page: Page; private readonly url: string; public readonly header_menu_login_link: Locator; public readonly main_contents_list_delete_button: Locator; public readonly modal_confirm: Locator; public readonly modal_confirm_ng_button: Locator; public readonly main_contents_card_add_button: Locator; constructor(page: Page) { this.page = page; this.url = "/top"; this.header_menu_login_link = this.page .locator("header") .locator("menu") .locator("li") .getByRole("link", { name: " ログイン", }); this.main_contents_list_delete_button = this.page .getByRole("main") .locator("list") .first() .getByRole("button", { name: " 削除" }); this.modal_confirm = this.page.locator(".modal .confirm"); this.modal_confirm_ng_button = this.page .locator(".modal .confirm .ng") .getByRole("button", { name: " キャンセル" }); this.main_contents_card_add_button = this.page .locator("main .contents") .first() .locator(".card button"); } } 設計カンファレンス extends OOC E2E テストの設計 / 戦術的設計 / Page Locator Book のススメ 48
49. Page Locator Book を作ると テスト実装時，ユーザーのインタラクションに集中してテストが書けるようになる 設計カンファレンス extends OOC E2E テストの設計 / 戦術的設計 / Page Locator Book のススメ 49
50. test(` アイテムを追加して，リストアイテムを削除しようとして思いとどまるシナリオ`, async ({ page, }) => { const topPage = new TopPageLocatorBook(page); await page.goto(topPage.url); await topPage.main_contents_card_add_button.click(); await topPage.main_contents_list_delete_button.click(); expect(topPage.modal_confirm).toBeVisible(); await topPage.modal_confirm_ng_button.click(); expect(topPage.modal_confirm).not.toBeVisible(); }); 設計カンファレンス extends OOC E2E テストの設計 / 戦術的設計 / Page Locator Book のススメ 50
51. Page Locator Book のススメ まとめ テスト実装時，ユーザーのインタラクションに集中してテストが書けるようになる テスト修正時，ロケーションは 1 箇所に集まっているので修正時に楽 テスト修正時，(命名センスに依存してしまうが…)ストーリーを追いやすい テスト修正時，Locator book とシナリオに分離されているので目が滑りにくい 複雑な事はしていないのでシンプルで始めやすい 設計カンファレンス extends OOC E2E テストの設計 / 戦術的設計 51
52. おまけ 設計カンファレンス extends OOC @fumiyaki 52
53. Connpass で申し込んだ当初は無職でした 設計カンファレンス extends OOC @fumiyaki 53
57. おわり 57