JaSST'20 Tokyo RejectCon
WebアプリケーションE2Eテスト⾃動化の3つの壁
View Slide
⾃⼰紹介末村 拓也(Takuya Suemura)⽊村拓也じゃないよQA / テスト⾃動化エンジニアというテスト⾃動化プラットフォームを作る会社で働いています
https://autify.com/ja/
E2Eテスト⾃動化してますか?
理想アサーションを⾃動化し、リグレッションの⾒落としを防げるようになる⾃動化により⾼頻度で実⾏できるようになるBDD・ATDDで振る舞いを保護しながら安⼼して開発が出来る
現実⾃動化は進んだものの……バグを検知できない⼿動でやればたくさんバグが⾒つかるのに……思ったより⾼頻度で実⾏できない実⾏速度が遅いどうでもいいところでコケまくる不安定不安定不安定不安定「また落ちてるな、リリース後に調べよう」→深刻な不具合
3つの壁バグ検出実⾏速度安定性これらを解決するための技術を広く浅く紹介してみます→深く話したい⼈は懇親会で!
バグ検出
E2E⾃動テストでバグを⾒つけるのは難しい網羅性が低い(網羅しようとするとテストケース数が膨⼤になってしまう)アサーションが無いところでバグが出がち「⼈がやってた時はバグを⾒つけられたのに……」
どうやってバグを⾒つけるか?基本的には「広く浅く」調べるようにするスナップショットテストビジュアルリグレッションテスト実⾏時エラーの検知
1. スナップショットテストHTMLの差分を⽐較する⽅法引⽤元: https://jestjs.io/docs/en/snapshot-testing
2. ビジュアルリグレッションテストスクリーンショットを⽐較して差分を⽐較する⽅法Original Current引⽤元: https://codecept.io/visual/#using-resemble-helper
引⽤元: https://codecept.io/visual/#using-resemble-helper
3. 実⾏時エラーを検知するクライアントサイド(JavaScript)やサーバサイドのエラーを取得する⽅法Sentryなどのサービスを使うとJavaScriptやサーバサイドのエラーをまとめて補⾜できる本番環境で使っているものをステージングやQA環境でも使うと良いTestCafe など、JavaScriptの実⾏時エラーを検知するとテストを中⽌する(失敗になる)フレームワークもあるSeleniumはログ取得のためのAPIを廃⽌したっぽい、悲しい
実⾏速度
E2Eテストの実⾏速度を早めるのは難しい実ブラウザを使う以上重い仕事になる要素の表⽰待ちなど暗黙の「待ち」が多い実⾏環境によってはネットワークレイテンシが強烈
アプローチテストデータをAPIやコマンドで作る状態をキャッシュする並列実⾏
1. テストデータをAPIやコマンドで作るテストデータもE2Eで作ってませんか?画⾯ A, B, C があるB, Cのテストをする前にAを操作しないといけないAが動かない場合B, Cのテストができない
1. テストデータをAPIやコマンドで作るAPIを使うコマンドラインから任意のメソッドを実⾏するRailsでの例: bundle exec rails runner 任意のコマンド
1. テストデータをAPIやコマンドで作るフロントエンド→バックエンドの通信部分だけを実⾏するF12 → Network タブ → Copy as fetch
2. 状態をキャッシュするE2Eテストの実⾏はCookie, キャッシュなどが無いクリーンな環境で⾏うのが定⽯しかしログインなどの処理を毎回E2Eでやるのは⾟い⼀度ログインしSessionIDを保存しておけば後で使い回せるTestCafeにはUser Roleという機能があり、難しいことを考えずに↑のようなことが出来る
3. 並列実⾏複数のマシン (or ブラウザ) で並列に実⾏させるhttps://www.browserstack.com/guide/selenium-grid-tutorial
並列実⾏の注意点テストシナリオにべき等性を持たせる必要がある何度実⾏しても同じ結果になるようにするシナリオに順序を持たせてはいけない
コンテナによる並列実⾏環境を構築するためのOSSChrome, FirefoxがインストールされたLinuxコンテナを必要に応じて⾃動で追加・削除してくれるZaleniumSelenoid商⽤サービスあり
安定性
E2Eテストは不安定要素の表⽰待ち外部サービスのエラー通信環境
筋⾁ リトライは全てを解決する
1. 失敗したステップをリトライする要素の表⽰を賢く待つよりも、リトライさせたほうが様々なケースに対応できるローディングスピナーが邪魔してクリックできないinputに⽂字⼊⼒できるようになるまでに時間がかかるURLが期待値に変わるまで時間がかかるステップのリトライ回数を設定できる場合は設定しておくと吉
2. 失敗したシナリオをリトライする外部サービスとの接続性などの問題で不安定になっている場合に有効規定の回数リトライし、⼀つでも成功すればOKとするステップと同様、デフォルトリトライ回数を設定しておくと楽
3. 不安定性を可視化するAllure Reporterでの例今までのテスト結果を全て保存しておき、失敗頻度が⾼いものに マークが付く
いかがでしたか?
E2Eテスト難しいこと多すぎ問題
そう、難しいんだ⾼レイヤーのテストになるほど時間とコストがかかるQAならみんな知ってるよね?E2Eでやらなくてもいいことはたくさんあるまずは難しさを理解することが重要E2Eでしか出来ないことに注⼒しよう
(余談)E2E = UIではないレンダリング + JavaScript実⾏の検証だけなら必ずしもE2Eである必要はないかもしれないPlaywright はつい最近Microsoftから発表されたChromium,Firefox, WebkitのテストをするためのツールAppliToolsのUltrafast Gridは任意のページのDOMスナップショットを複数のブラウザでレンダリングし⽐較するUIテストが実機の縛りを抜け、E2Eテストの責務を減らし、シンプルに実現できるようになる
3つの壁バグ検出実⾏速度安定性
壁を乗り越えた先は⾼速・⾼頻度で実⾏されるテスト広範囲でバグを検出できるテスト安定動作するテスト
難しいこともあるけど楽しく乗り越えていきましょう
Enjoy Testing!