フロントエンドのテスト効率化イベントのセルフレポート

はじめに

こんにちは！株式会社POLでエンジニアをやっている @show_kanamaru です！

POLは「研究者の可能性を最大化するプラットフォームを創造する」をビジョンに、理系学生に特化した採用サービス、および研究開発者・技術者に特化した転職/採用サービスの2サービスを運営しています。

3/4(木) 20-22で開催されたヤフー株式会社主催の「MixLeap Live Study #64 - フロントエンドのテスト効率化」に参加してきました。
最近業務でE2Eテストを書くことがあったので、今回はE2Eテストについての発表をまとめてみます。

E2Eテストとは

システム全体が正しく動作することを確認するもの。 具体的には「利用者による画面操作（Web ブラウザの操作）により、想定通りの動作となっていることを確認する」ことを指す。

テストケースを作って手動でテストをしている方々も多いのではないでしょうか？手動だと時間がかかったり、漏れがあったりとデメリットが多いと思います。これらを解決してくれるのはE2Eテストですね。

今回はこのE2Eテストに関して、Yahoo! JAPANのトップページのSP版を開発している史 宇華さんが発表をしてくれたので、簡単にまとめたいと思います。

動作確認のコスト

Yahoo! JAPANは動作確認のコストが高いらしい。

原因としては・・・

多数な機能
・天気
・災害情報
・etc

多様なユーザー属性
・地域
・ログイン
・etc

あれだけの規模のサービスのトップページですもんね、テストケースとかえげつなさそう。。

さすがに手動でのテストは限界。。。ということでE2Eテストの導入に挑戦することに。

ただ、E2Eテストを書いたことある方はよくご存知かもしれませんが、E2Eテストの導入はなかなか大変なんですよね。

E2Eテスト導入の一般的な課題

①失敗しやすい
・ネットワークの遅延
・外部JS・APIへの依存

②フィードバックが遅い
・テストの実行時間が長い

③コストが高い
・導入コスト

④メンテナンスしにくい
・デザインの変更
・新規機能の追加

上記の理由から頑張って導入したけど陳腐化してしまうパターンが多い。

僕たちのチームでもログイン処理のE2Eテストを書いているのですが、ネットワークの遅延でログイン処理に時間がかかり、ログイン後のDOMの要素を取得できなかったり、KarteによるモーダルでE2Eがコケてしまっていたり。まだ書き始めたばかりなのですが、すでにエラーが出まくっていました。

そんな導入コストが非常に高いE2Eテストを陳腐化させないためには・・・

・安定性を高める
・開発チームへの導入をサポートする

ことが重要。

安定性を高める

①リリース時以外にも定期的に実行
・失敗したら通知を送る
・テスト頻度を上げ、不安定なテストを特定

②失敗したら最優先で原因究明
・成功率の低いテストはまずskipしてから調査
・失敗時のスナップショット、ログを残す
・テストレポートを残す

①に関して、僕たちのチームではリリース作業の一番最後にE2Eテストが回るようになっているため、E2Eテストがコケるとこんな感じの通知が来てしまいます。

E2Eテストが原因とは気づかず「リリースどっかでコケてるぞ！」と焦ることになりますね。

史さんのチームではテストが失敗したら以下のようなフローになっているらしい。

・CI上であるE2Eテストが失敗したメッセージが来る
・エラーメッセージの内容をみて失敗したテストを特定する
・失敗したテストを一旦skipする
・エラーログ、スクリーンショットを記録してissueを切る
・原因を分析して、テストを修正する
・テストを有効にして、テスト結果を観測する 

開発チームへの導入をサポートする

いきなりチーム全体に浸透させるのはハードルが高いので、まずはスモールチームスタートが大切。

- 開発サイクルを短め
- 方針の理解浸透を徹底
- 知見収集、ベストプラクティス模索
- 安定する書き方とルール策定

スモールチームでこれらが浸透して初めて全体に展開したらしい。いきなり全体にはやっぱり難しいし、1人で推進するもの難しいですよね。協力してくれそうな人をいかに巻き込むかが大事になってきますね。

利用したツール

Playwright
・Microsoft製OSS、Puppeteerの上位互換
・2020年5月に正式リリース

良いところ
・使いやすいAPI
・Chromium、WebKit、Firefox対応
・ヘッドレスモードでコンテナ環境内実行可能

いまいちなところ
・新しいOSSなので資料が少ない
・環境による実行結果がたまに違うのでデバッグしにくい

僕たちはTestCafeを使っているのですが、Playwrightは触ったことがありませんでした。史さんも一通り全部書いてみてPlaywrightを選んだと言っていたし（決め手はwebkitに対応していることらしい）、GithubのStar数もPlaywrightのほうが多いので触ってみようと思います。

できたこと

史さんのチームで実際に達成できたことは以下。

安定性を向上したうえ、維持している
・成功率を導入直後の60%から95％へ向上し、維持している

開発サイクルを早めて短期間で知見収集・ルール策定ができた
・プロダクト全体へのセミナー・ハンズオンを通じて展開した

最後に

僕たちもこれからE2Eテストを運用していこうとしているので、イベントの話を参考にチームメンバーを巻き込んでいこうと思います！

POLでは新しい仲間、エンジニア、デザイナー、プロダクトマネージャーを探しています！他にも職種あります！！お話しだけでも構いませんのでお声がけください！！！