E2E Testを導入した話 - High Link テックブログ

こんにちは。プロダクト開発エンジニアのプリン(@プリン)です。High Linkでは主にフロントエンドを担当しています。最近は趣味でプログラミング言語のZigを触っています。

本題ですが、カラリアの開発でE2E Testを始めたのでその取り組みを紹介させていただきます。

前提条件

弊社では「カラリア香りの定期便」を開発しています。

カラリアのバックエンドがRuby on Railsで実装されているのに対し、フロントエンドはReact(Next.js)で実装されています。なので以下はReactを前提にお話しさせていただきます。

カラリアフロントエンドの課題

バックエンドはテストが拡充されていますが、フロントエンドにはほとんどテストがありません。

そして最近はグロースの勢いが加速し機能追加が増えてきています。直近では金曜を除き毎日5回前後、リリースされています。それに伴いフロント起因の障害が発生することが増えてきました。特にカラリアの会員登録でバグを埋めてしまうのはサービスの売り上げにダイレクトにダメージを与えるため、絶対に避けたいものです。

そこで、機能追加のスピードを落とさずに定期便登録に問題がないことを確実に担保するべくE2E Testを導入することにしました。

E2E Test

フレームワークはPlaywrightを選定しました。理由は以下の2つです。

記述が一番シンプルで工数が抑えられそうなため
カラリアのユーザーのブラウザ比率はiOS Safariが一番多く、Webkit上でテストできるため

他のフレームワークとの比較などもしましたがここでは割愛します。

実際のテスト内容は、一般的な新規ユーザーがサイトに訪問し、検索、アイテムを選択などを経てカラリアの定期便サービスに登録する一連の流れを再現する形になっています。

PlaywrightのUI Modeで見るとこんな感じです。(実行している時は早すぎて追えないのでカーソルで流し見しています

youtu.be

カラリアでは変更がmasterブランチにマージされるとStaging環境にデプロイされ、その後問題なければmasterブランチのコードが本番にリリースされる流れになっています。

その中でE2E TestはGithub ActionでStaging環境にデプロイされた後に走るようになっています。

name: E2E Tests
on:
  workflow_run:
    workflows: ["Staging Deploy"]
    types: [completed]

...

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    env:
      ...
    steps:
      - uses: actions/checkout@v4
      ...
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        continue-on-error: false
        run: npx playwright test

そしてその実行結果は playwright-slack-report でSlackに通知されるようにしています。

これによって定期便登録フローに致命的なバグが混入してもリリース前に気づけるようになりました。

E2E Testを整備した所感

プロダクトをリリースする際にE2Eがあることで安心感はかなり得られるようになりました。

具体的には、このE2E Testが整備されるまでは実装者各々の手動テストに頼っていたため、それが抜けてしまうリスクが常にありました。それがE2Eに移譲できたので精神、労力ともにかなり楽になりました。ただ以下の課題感を感じるようになりました

E2E Testのメンテコストが高い

分かりきっていた話ですが、E2E Testは実行コストが高いので単体テストのようにローカルで機能の変更と同時にさっと修正することはできません。また先ほど述べたようにカラリアの機能追加のスピードは日々増していく一方なので、それに付随してメンテコストが増えるのは目に見えています。会員登録画面では必要性がそれを上回っているので許容できるですが、カラリアのサービス全体をカバーしようとするのはとんでもないメンテコストになるので許容できないと感じました。

そこで会員登録画面以外では気軽にローカルで実行、修正できるIntegration Testを導入し、これから拡充しようと考えています。これはKent C. Dodds氏が提唱しているTesting Trophyという考えにも合致しています。E2E Testや単体テストは最小限にしてIntegration Testを拡充すべきという考えです。

"The Testing Trophy" 🏆

A general guide for the **return on investment** 🤑 of the different forms of testing with regards to testing JavaScript applications.

- End to end w/ @Cypress_io ⚫️
- Integration & Unit w/ @fbjest 🃏
- Static w/ @flowtype 𝙁 and @geteslint ⬣ pic.twitter.com/kPBC6yVxSA
— Kent C. Dodds 🌌 (@kentcdodds) 2018年2月6日