E2E自動テストのFlakyに対処しようと思ってAPIでArrangeしてみたの

Transcript

1. E2E自動テストのFlakyに対処しようと思ってAPI でArrangeしてみたの 2024.04.16 Tue. JaSST nano vol.35 たぬ（@nagatanuen）
2. たぬ（X: @nagatanuen） SmartHR QAエンジニア 経歴： 某SES（5年） 　株式会社SHIFT（3年） 　株式会社SmartHR（3年） 自己紹介
3. スクフェス新潟に登壇します（未承諾広告※） スキルアップしたくてE2Eテストに チャレンジしてみた 5/11(土) 15:00 ~ 15:20 https://confengine.com/conferences/scrum-fest- niigata-2024/proposal/19691/e2e
4. • E2E自動テストを実装・運用しているなかで誰もが一度は目にする Flaky（一度…？） • Flakyを減らす工夫はいろいろあると思いますが、今回は APIを併用するということを考えて取り組ん でみたので紹介します ◦ あくまでひとつのアイデアとして聞いてください 🙏 ◦ （チームのテスト方針によって適切な書き方は異なると思うので） 今日お話しすること
5. E2E自動テストのFlakyに対処しようと思ってAPIでArrangeしてみたの このタイトルにある、FlakyとArrangeについて説明します。 用語解説
6. 同一のテストでも実行結果が異なることを Flakyと言います。 E2E自動テストがFlakyになりがちな理由には、テストを実行する際にさまざまな要素が絡み合っていること が一因にあります。 絡み合ってるモノの一例： • インターネット通信 • UIのレンダリング • ブラウザ • プロダクトコードで呼び出しているライブラリ • インフラリソース Flakyとは
7. 結論から言うとダメです。 プロダクトコードは正しいはずなのに、テストが失敗する状態になります。それが常態化するとテストの実 行結果に対する信頼が損なわれ、本当にテストが失敗しても気付けなくなってしまうおそれがあります。 （これを偽陽性といいます。） 信頼できるテストを回し続けるために、 Flakyには対処する必要があります。 ここらへんの話は、t_wadaさんの記事がわかりやすいのでオススメです。 第2回 偽陽性と偽陰性 ～自動テストの信頼性をむしばむ現象を理解する～ | gihyo.jp Flakyはダメなの？
8. AAAパターンのArrangeを指しています。AAAパターンは、テストコードの可読性を高めるためのパターンです。以下３ つの頭文字を合わせた名称になっています。 • Arrange (準備) ◦ テストを行うための状態をセットアップします。これには、オブジェクトの生成、値の設定、依存関係の注 入などが含まれます。 • Act (実行) ◦ テスト対象のコードを実行します。通常は、一つのメソッドや機能に対して実行が行われます。 • Assert (検証) ◦ Actで行われた操作の結果が期待通りであることを確認します。これには、戻り値のチェックやオブジェク トの状態の検証などが含まれます。 Arrangeとは
9. E2E自動テストのデータ準備をAPIに置き換えてみたの やったこと
10. ［お知らせ］から［年末調整画面］への動線をテストしたい 題材
11. テスト手順 1. 管理者でログインする 2. 管理者でお知らせを作成し、送信する • 「年末調整の回答依頼が発行されたので確認してね」という内容 3. 従業員でログインする 4. 従業員でお知らせをクリックする 5. 年末調整画面が表示されること 題材：［お知らせ］から［年末調整画面］への動線をテストしたい AAAパターンに当てはめると以下のようになる。 　Arrange（準備）：1 ~ 3 　Act（実行）：4 　Assert（検証）：5
12. 以下のように、Arrangeの部分のステップが多い。 1. ログイン画面を表示する 2. 管理者のメールアドレス・パスワードを入力し、ログ インする 3. お知らせ管理画面に遷移する 4. お知らせの内容を入力する 5. お知らせを送信する 6. 別セッションのブラウザでログイン画面を表示する 7. 従業員のメールアドレス・パスワードを入力し、ログ インする AAAをすべてEnd to Endで書く場合
13. ArrangeをAPI Requestに置き換えた場合 「管理者でお知らせを送信する」が１ステップに。 1. ログイン画面を表示する 2. 管理者のメールアドレス・パスワードを入力し、ログ インする 3. お知らせ管理画面に遷移する 4. お知らせの内容を入力する 5. お知らせを送信する 6. 別セッションのブラウザでログイン画面を表示する 7. 従業員のメールアドレス・パスワードを入力し、ログ インする
14. • APIに置き換えたことで安定し、 Flakyは起きなくなりました ◦ 実行ステップの削減と、 APIの高い安定性を用いることで Flakyに対処できました • また、副次的にテストの実行速度が向上しました ◦ 画面遷移やUIのレンダリング、フォームへの入力待ちの時間が削減されたためです ▪ APIとE2Eでは35倍の速度差があるケースも ▪ UI Automation Vs API Automation - Quality Spectrum APIに置き換えた結果...
15. • APIに置き換えた部分は End to Endではなくなるということには留意しなければいけません ◦ APIに置き換える部分は別のテストで担保されている必要があります ◦ 今日の題材でいうと「管理者でログイン〜お知らせを送信する」の部分です • また、APIに置き換えなくとも、テストのステップを削減する方法はあるので、それらの利用も検討し ましょう ◦ 例えば、Playwrightにはセッション情報をあらかじめ用意しておく仕組みがあり、用いることで ログインのステップを省略することができます ◦ https://playwright.dev/docs/auth#session-storage APIに置き換えるときに気にすること
16. ご清聴ありがとうございました！ おわり