動作する読みやすいE2Eを目指して/Aim for readable E2E

XP祭り2024の発表資料です。

Transcript

1. 動作する読みやすい E2Eを目指して 2024/9/28 XP祭り
2. 2 藤原 考功(Takanori Fujiwara) ・株式会社ユーザベースの社員(テストエンジニア) ・XP祭り実行委員 ・JSTQB(Japan Software Testing Qualification Board)技術委員 自己紹介 https://www.shoeisha.co.jp/book/detail/9784798186061
3. 3 E2Eテスト(以下、E2E)に対する改善活動 今日お話しすること
4. 4 • 画面やAPIなどの仕様を、 利用者の立場で記述する • 上記に、動作を確認するための手順が 自動テストとして紐付いている 本セッションにおける「E2E」
5. 5 • 動作するドキュメント ◦ 利用者の立場から見た仕様が書かれている ◦ 自動テストとして動かすことができる　 本セッションにおける「E2E」 特に、最新の仕様がタイムリーに反映されていることが重要だと思っています
6. 6 • 仕様を理解できる記述になっている ◦ 利用者の立場から見た仕様が書かれている • 安定して動作する ◦ 自動テストとして動かすことができる　 「E2E」が備えていてほしい要素 発表の都合上、後者の「安定して動作する」の方を先に話します
7. 7 • GaugeとSelenideを採用 • 自然言語で記述し、テストコードと紐付ける　 私たちのチームの場合
8. 8 紐付けの例
9. 動作するE2E | 01 | 9
10. 10 ・まずは最低限動作するコードを書く ・テストがGreenな状態を保ったまま 　コードを綺麗にする テスト駆動開発の考え方
11. 11 ・まず安定して動作することが大事 ・動作しない(特に不安定な)テストコードは 　余計なストレスを生む ・安定して動くから安心して試行錯誤できる E2Eにも同じことが言えるはず
12. 12 ・安定しない原因を愚直に調べる ・安易なリトライもなるべくやめる どうしたら安定するのか
13. 13 ・画面を開く ・画面の描画が終わるまで待つ ・画面内の要素を検証する 例えば、「待ち」を改善する
14. 14 ・画面を開く ・画面の描画が終わるまで待つ←ここが抜けがち ・画面内の要素を検証する 例えば、「待ち」を改善する
15. 読みやすいE2E | 02 | 15
16. 16 テストコードは常に具体的な手順として 細かく書く必要があるので、 記述量が多くなりがち E2Eが読みづらくなってしまう理由 その1
17. 17 ・ログイン画面を開く ・ログイン画面が表示されるまで待つ ・ユーザー名に「username」を入力する ・パスワードに「password」を入力する ・「ログイン」ボタンを押下する 記述量(手数)が多い例
18. 18 対策：1行に置き換えて隠す
19. 19 ・記述しない...は無理なので、 　何らかの形で構造化する ・インデントする、色を分ける、 　ファイルを分ける etc… 記述量への対策
20. 20 ・具体的な事実しか書かれておらず、 　仕様そのものや、なぜその仕様になったか 　といった情報が欠落している E2Eが読みづらくなってしまう理由 その2
21. 21 ・上映開始時刻が21:30である場合、 　料金として1,500円を表示する 具体的な事実しか書かれていない例 仕様が読み取れない!!
22. 22 対策：仕様がわかる記述に置き換える
23. まとめに替えて | 03 | 23
24. ・安定して動作するE2Eを手に入れるために、 　安定しない原因を少しずつ潰す ・綺麗で読みやすいE2Eを手に入れるために、 　具体的(すぎる)記述に少しずつ手を入れる 24 動作する読みやすいE2Eを目指して 結局、こまめな片付けが大事ってことなんだと思います