自動テストを作りました！！！！

なんでそんなことをしたのかという話

とあるプロジェクトのリリース前には、割と莫大な量のテストを行う必要がありました。

しかも週一ペースで、手動で。なんとな～く想像はつくと思いますが、超超超時間がかかった訳です。

チームメンバーに担当か所の割り振りして、画面のスクショとって、エビデンス作って、エビデンスの再鑑して…

『スクリーンショットの画面が足りないからテスト最初からやり直し！！！！！』

『エビデンス、この項目足りてなくない？ちゃんと見た？』

『テストの進みが遅くない？リリース間に合う？』

『エビデンス格納のExcelが超重い😡😡😡😡😡』

『期限までに間に合わない😭😭😭』

みんな人間なので、集中力もいつかは切れます。

私たちの悩みはいつも1つ……

『『『リリース前の手動チェックに時間がかかりすぎるよ～～～😭😭😭』』』

この悩みを解決してくれるのが、Playwrightってわけ。

Playwrightのおかげで、10人規模で約3週間も時間がかかっていたテストが、4人で半日で終わるようになっちゃったんですね～～～！！！

マジで素晴らしい。Playwrightでの開発に関わってくださった人達みんな最強！！！褒めてほしい。

☺️＜えらいね～

↑うれしい

Playwrightってなにもの？

一言でいうと、「ユーザーが実際にサイトを操作するのと同じ流れ（エンドツーエンドテスト）を、自動で実行してくれる超強力なツール」です。

Playwrightの公式Documentのリンク貼っておきます。

詳しくはそちらを参考にしてください。

https://playwright.dev/docs/intro

Playwrightのここがすごい

1. あらゆるブラウザに対応🌐

Playwrightは、Google ChromeやMicrosoft Edgeの元になっているChromium、Safariの元になっているWebKit、そしてFirefoxという、世界の主要なブラウザエンジンをすべてサポートしています。これにより、「このブラウザだけで動かない」といった問題を確実に捉えることができます。

2. どんな環境でもテスト可能 💻

あなたのPCがWindowsでも、Macでも、Linuxでも問題なく動作します。さらに、テスト実行中にブラウザ画面を表示させて動きを確認したり（ヘッドフル）、裏側で高速に実行したり（ヘッドレス）することも可能です。開発中のデバッグから、CI/CDツールと連携した自動化まで、あらゆるシーンで活躍します。

私たちが実装した自動テストの詳細

ブラウザ
- Chromium
実装環境
- Windows
自動テストの機能
- 画面操作
- スクリーンショットを撮影
- 文字検証

Playwrightを使えるようにする手順

ここからは、Playwrightを使うためのアレコレを簡単に説明していきます。

コマンドに関してですが、コードブロックにするとますます読みにくくなるので太字にしてます。許して。

環境構築・設定のやり方（Playwright実装用のリポジトリがある場合）

管理者用でターミナルを開く
npm install -g yarnを行い、yarnを確認する
→既に入っている場合、file already existsと表示される
git clone（gitのhttpsをコピー）する
クローンしたリポジトリをVScodeで開く
ターミナル（GitBash）でyarn installを実行
yarn playwright installを実行
yarn playwright install-depsを実行
拡張機能 Playwright Test for VSCodeをインストール
拡張機能のインストール後、VSCodeの再起動を行う
VSCodeのサイドバーにフラスコマークの「テスト」が追加されるため、それをクリック
PLAYWRIGHTをクリックし、以下の項目にチェックを入れる
・PROJECTS の chromium
・SETTINGS の Show browser

環境変数の設定手順

.envという名前のファイルを作成する
.envファイルに環境変数を設定する
テストケースのpath設定はここで行う

フォルダ構成

tests/ Playwright テストの本体
- テストファイル名.spec.ts playwright によるテストの記述
  all.spec.tsで全テストケースが網羅されている
  テストケースごとに実行できる
constants/ テスト間で使いまわす定数の置き場
interfaces/ テストで利用するインターフェース
utils/ テスト間でサブルーチン的に使えるテストフローなどの置き場
.env/ (Git リポジトリ上にはない) playwright のテスト時の環境変数設定ファイル
.env.sample/ .env ファイルに書く内容のテンプレ
playwright.config.ts/ Playwright の設定ファイル

テストケース追加方法

Excelで空白のブックを開く
A1セルを左端として、１行目にヘッダー項目を記入する
A2以下の行は、作成したいテストケースを入力する
例：アイスを注文するテストケース
テストケースを記入し終わったら、拡張子を.csvに変更して保存する
保存したテストファイルを環境変数やコード上に設定してテストデータを読み込む

⚠️注意⚠️

上記のテストケースはブログ用に限りなくわかりやすくするための例であり、実際のテストケースはもっとヘッダーの量が多くなります。

CSVをオブジェクトに変換する

今回のテストではCSVを読み込んだ後、interfaceで型付けを行いました。

TypeScriptexport interface OrderInfo{
	iceInfo: IceInfo[],
	containerType: string,
	notes: string
}

TypeScriptexport interface IceInfo{
	iceName: string,
	size: string,
	quantity: int,
}

こうすることで

型安全性の向上
コードの可読性の向上
リファクタリングの容易さ

などのメリットがあります。
CSVは構造が単純なので、IceInfoなどリストの長さを自由には変えることはできません（そのためにはメニュー１、メニュー２、メニュー３と列を増やす必要がある）。ですが、今回はテストケースを量産したかったので、リストの長さは最大2を想定してCSVを作成しました。

テスト実施方法

サイドバーの「フラスコ」マークの「テスト」をクリック
「＞テストエクスプローラー」をクリック
「＞tests」が表示されるので、それをクリック
「＞all.spec.ts」をクリックすると、.envで設定したテストケースが表示される
「テストの実行」をクリックすると、青いChromeのようなものが立ち上がりテストが実行される

テスト実施における注意点⚠️

テストを行うたびにreportが発行される仕組みになっており、エビデンスとして格納する必要があります。

しかし、テストを回し終えた際に、続けて別のテストを行ってしまうとreportが上書きされてしまい、前回実行したテスト結果がなくなってしまいます😖

reportの上書きを防ぐため、テストを行う際はテストエクスプローラーのリロードを行ってからテストを実行すると新規reportとして保存されるので、リロードをしないままテストを実行してしまわないように気を付けましょう！

テストを実施するときのポイント

テストが通らない🤔

自動テストの操作が早くてPCの処理が追いつかなかったり、ネットワークの問題でモーダルが表示されなかったり、『いつもテスト成功してくれるのに、どうしてそこで失敗するんだ…？』となることがあります。私たちは割と高頻度でありました……。

この問題を明確に解決する方法は無いですが、自動テストを行っている画面をバックグラウンドにせず、表示させておくだけでテストが完了まで通りやすくなるので、困った際はやってみてください。（けど正直気休めレベル！これやってみたらうまくいく時が多くなった感覚はある！）

特定のテストケースだけ実行したい🤔

Ctrlを押しながら実行したいテストケースのみクリックすると、クリックしたテストのみ実行することができます。

全部のテストケースを実行した後に、失敗したテストケースだけやり直すときなどに便利！

出力されるエビデンス

playwright-report

テストを実行する度にreportが出力される。

data
まとめて行ったテストのスクリーンショットやPDFが格納されている
index.html
テストが成功したか、失敗した場合どの部分で落ちたのかが記録されている

その他自動テスト内で出力されるようにしたもの

今回の場合だと、私たちはエビデンスの信憑性を高めるためにスクリーンショットを撮影し、出力する機能を付け足しています。この辺は各プロジェクトによって色々違うと思うので、臨機応変に対応してください。

Playwrightを触ってわかったこと

Tailwind CSSとPlaywrightの相性と、変更に強いテストの書き方✒️

Tailwind CSSは、mr-1（margin-right: 4px）のように、見た目のスタイルをそのままクラス名としてHTMLに記述するライブラリです。この仕組みは、UIを少し変更しただけでクラス名が変わってしまうため、クラス名に依存したPlaywrightのテストは脆くなりがちです。しかし、この課題はテストの書き方次第で克服できます。変更に強いテストを書くには、テストの目的が操作の「実行」なのか「検証」なのかを意識し、アプローチを変えることが重要です。

１．操作の「実行」は、変更に強い😄

ボタンをクリックする、フォームに入力するといった「実行」が目的のテストは、UIの変更に強く作ることができます。Playwrightでは、mr-1のような変わりやすいスタイリング用のクラスではなく、getByRole()などユーザーの操作に紐づく方法で要素を特定することが推奨されます。このアプローチを取れば、UIのデザインが変更されてもテストは安定して動作します。

２．クラス名に依存した「検証」は、変更に弱い😞

一方で、クラス名を頼りに要素を特定し、その内容を検証するテストは、UIの変更に非常に弱いです。例えば、「ボタンの余白を広げる」という軽微なUI修正でクラス名がmr-1からmr-2に変わったとします。このクラス名を頼りに文字を検証していたテストは、機能的には何も変わっていないにも関わらず失敗してしまいます。これは、デザインの変更に直接影響される、脆いテストと言えるでしょう。