1
/
5

【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フロントエンドリプレイス環境における自動テストは以下の構成としました。

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

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


前提

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

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


Vitestによる小さなテスト



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

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

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

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

その他検討したテスト

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

続きはこちら

株式会社ZOZO's job postings
1 Likes
1 Likes

Weekly ranking

Show other rankings
Invitation from 株式会社ZOZO
If this story triggered your interest, have a chat with the team?