普段翻訳などしないし、別に丁寧に日本語訳などはしません。

カタカナで馴染み深いものはそのままに、自分で再度読みやすいように。

括弧内は意訳した部分の直訳や原語のカタカナママだったり、私が付け足した補足だったり。

ベストプラクティス

イントロダクション(巻頭言)

このガイドはきっと、我々のベストプラクティスに従い、そして、より弾力性のある(レジリティな)テストを書く助けとなることでしょう。

自動化されたテストはエンドユーザー(一般消費者)のためのものであり、次のような実装の詳細に頼ったりすることは避けねばなりません。

ユーザーが使ったり、見たり、ましてや知り得ない情報。例えば、関数の名前だとか、それが配列であるか何かのDOM要素のCSSクラスであるかの区別とか。

エンドユーザーはページに何がレンダリングされたかを見て、インタラクトする(だけな)のだから、

あなたの書くテストも典型的にはレンダリングされたものを見て、インタラクトするだけであるべきです。

各テストは他のテストから完全に孤立しているべきで、

他のテスト自身のローカルストレージや、セッションストレージ、データ、cookieなどとは独立して実行されるべきです。

テストの孤立性はテストの再現性を高め、デバッグを容易にし、そしてテストが連鎖的(カスケーディング)に失敗するのを防ぎます。

(その目的を達成するに当たって、テストの一部を繰り返したいことがあるでしょうが、)

(あなたの)テストの特定の一部の繰り返しを避けるために、before and after hooks を使うことが出来ます。

テストファイルにbefore hookを付け加えることで各テストの前に、

例えば特定のURLを開いたり、あなたのアプリケーションの一部にログインしたり、というような、

テストのある一部を実行することが出来ます。

これによってあなたのテストは互いに依存せず孤立させられるでしょう。

しかしながら、テストが十分シンプルで、そのままの方がより明快で読みやすくメンテしやすいなら、小さなデュプリケーションはあっても良いでしょう。

(コード例)

また、ログインステートについては、setup projectを用いることでも使い回すことが出来ます。

そちらの方法であれば、ログインは1度で済み、全てのテストでログインの手順を省略することが出来ます。

あなたの管理下にあるものだけをテストしてください。外部サイトのリンク(先)や管理下にない他者のサーバーのテストを試みないでください。

それ(テストを試みること)自体が時間の浪費であり、テストが遅くなるというだけではなく、リンク先のページのコンテンツは管理出来ず、

cookieバナーだったり、オーバーレイだったり、他の何かだったりが有るだけでテストが落ちる原因になり得ます。

代わりに、Playwright Network APIを使って必要なレスポンスを保証してください。

(コード例)

DB(を用いたアプリ)を使っている場合はデータをコントロールしていることを確認してください。

ステージング環境でテストし、それが変わらないことを確認してください。

視覚的なリグレッションテストの場合はOSとブラウザのバージョンが一致している(固定されている)ことを確認してください。

以上問題があれば消します疲れたので実際のベストプラクティスの方はもうちょっと気が向いたら。