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

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

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

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

WEAR Webフロントエンドリプレイスのアーキテクチャ選定とNext.jsへの移行 - ZOZO TECH BLOG

こんにちは。WEAR部フロントエンドブロックの藤井です。 WEAR では現在、Webサイトのリプレイスを進めています。本記事では、リプレイスに至った背景や課題と、課題解決のために行ったリプレイスのアーキテクチャ選定についてご紹介します。 ...

https://techblog.zozo.com/entry/wear-web-frontend-replace-with-next-js

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

はじめに
- 前提
構成の決定と判断
- QAチームによるE2Eテスト
- Playwrightによるビジュアルリグレッションテスト
- Vitestによる小さなテスト
その他検討したテスト
おわりに

はじめに

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

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

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

前提

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

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

構成の決定と判断

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

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

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

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ではデフォルトでこのテストは実行されず、特定のラベルを付与するか、マージしたタイミングで実行されるようにしています。