WEAR Webフロントエンドの自動テスト構成 2023

WEAR フロントエンド Test

こんにちは。WEAR Webフロントエンドチームの冨川 (@ssssota) です。

私たちのチームでは普段WEARのWebフロントエンド全般の開発から運用までを行なっています。また、あと半年ほどで10年になるVBScript+jQuery環境からNext.js/React環境へのリプレイスを進めています。

リプレイスの詳細は弊チームの藤井が書いた記事をご覧ください。

techblog.zozo.com

本記事では、WEARのWebリプレイス環境における自動テストの構成について紹介します。自動テストの構成を悩んでいる方の決断の一助になれば幸いです。

はじめに

先に結論を述べますが、WEARのWebフロントエンドリプレイス環境における自動テストは以下の構成としました。

「ビジュアルリグレッションテストを主軸とし、小さなテスト1を適宜拡充する」

自動テストは、いかに開発速度を向上させられるかに着目して考えました。

前提

この決定をするにあたり判断材料となったいくつかの前提条件を述べます。

  1. 割ける工数 現在のWEAR Webフロントエンドチームは4名で機能開発やリプレイス、運用改善などが行われています。リプレイスに注力できるのは、時によって変動はあるもののおよそ2名前後です。いくらでも時間をかけられるわけではないのでスピード感も鍵となります。
  2. QAチームによるテスト 本記事では、自動テストの構成について紹介していますが、その構成の根底にはQAチームのエンドツーエンドな自動化されたシナリオテストと手動による探索的テストがあります。最低限の品質はここで担保されるということ、また、テストの重複などによるロスを減らすことも鍵になります。
  3. インタラクションの量 WEARのWeb版は、コーディネートの投稿機能などは持っていません。ページにもよりますが、テストするべきインタラクションはかなり限定されています。

構成の決定と判断

今回は、以上のような条件から「規模（カバー領域）」と「コスト」にフォーカスし構成を決定しました。

要素を簡易的な図にしたものがこちらです。

テストの規模を横軸、コストを縦軸に置いた図。第一象限にQAチームによるE2Eテスト、第三象限に小さなテスト、第四象限にビジュアルリグレッションテストが配置されている。

それぞれの要素について解説します。

QAチームによるE2Eテスト

前提の紹介でも述べていますが、WEARにはQAチームが存在し、機能リリース時などに開発チームと連携しながらテストを行なっています。

機能リリース時とはいえ探索的なテストも行われるため、高い確度で品質が保証されます。QAチームの存在により「リグレッションをいかに防ぎ、開発速度を上げられるか」という観点で構成を考えるに至りました。

Playwrightによるビジュアルリグレッションテスト

低いコストで広い範囲をカバーできるという点からPlaywrightを用いたページ単位のビジュアルリグレッションテストを採用しました。

QAチームによるテストが行われるタイミング以外でも細かなリリースは行われるためにデザイン崩れが発生していないことを保証するために行われます。前提でも述べた通り、WEARのWeb版はユーザーによるインタラクションが限定されているためにページのスクリーンショットに差分がなければ挙動としてもある程度の保証がされるという判断をしています。

Playwrightによるビジュアルリグレッションテストのコードの一例を示します。

import { test, expect } from '@playwright/test';
test('Visual Regression Test sample', async ({ page }) => {
  await page.goto('/some/target/page');
  await expect(page).toHaveScreenshot({ fullPage: true });
});

Playwrightの設定を済ませた上で上記の様なコードだけで1つのページのスクリーンショットが撮影、差分チェックできます。

Playwrightのスクリーンショット撮影時は自動的にアニメーションも無効になる（opt-inで有効にできます）ので不安定さを回避できますし、必要に応じてボタンクリックなども利用できます。

実際の運用としては、このテストではAPIはMSWを用いたモックデータが利用されネットワークの不安定さを極力減らしつつ行っています。また、Pull Requestではデフォルトでこのテストは実行されず、特定のラベルを付与するか、マージしたタイミングで実行されるようにしています。

Vitestによる小さなテスト

簡単なロジック、UIなどの小さなテストにはVitestを採用しています。

こちらは、Playwrightとは対照的にすべてのPull Requestで実行されます。

JestではなくVitestが採用されているのは、多くの場合で設定量が少なく済む点、トランスパイルが高速な点です。Jestでもtransformerを設定することでトランスパイルの速度を改善できますが、設定にさまざまな検討の余地が生まれてしまいます。

Pull Requestで実行されるテストは静的解析の他には、この小さなテストが主になります。ビジュアルリグレッションテストがPull Requestでは実行されないこともあり、Pull RequestでのCIの実行時間は平均で2分に収まっています。

その他検討したテスト

直近では採用しなかったものの利用していた、もしくは利用を検討したテストを紹介します。

  • Cypress
    • 以前はComponent Testを利用していたがCypressの書き方が独特な点、他テストと比較してFlakyさをハンドルしづらい点など開発コストが高いためフェードアウト
  • Playwright Component Testing
    • Cypress Component Testの移行先として検証していたがExperimentalということもありここにコストを掛けるのは時期尚早と判断
  • Chromatic (Visual Regression Test)
    • 導入はしているものの毎PRテストするかなど運用に課題
    • StorybookのStoryをテストでき開発コストは低く恩恵を受けやすいため、今後、運用体制を整える予定

おわりに

WEARのWebリプレイス環境における自動テストの構成を紹介しました。開発速度の向上を主目的に「ビジュアルリグレッションテストと小さなテスト」を利用する構成です。

自動テストは一朝一夕で設計・構築できるものではありません。今回紹介した様に、プロダクトの性質、開発体制、開発フェーズ、自動テストの目的および、その時点でのゴールなどを明確にした上で中・長期的に向き合うことが大事だと思います。

WEARではこのようなサービスの品質改善に興味があり、一緒に作り上げて行ける方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com

  1. 小さなテストという名称を用いているのは、ユニットテストという単語の曖昧性を避けるためです。和田卓人氏が執筆された記事「テストサイズ ～自動テストとCIにフィットする明確なテスト分類基準～」よりSmallテストを本記事では小さなテストとしています。↩
カテゴリー