Structured Playwright (1) —— 継続性から設計するE2Eテストの4層構造とハーネス
はじめに：E2Eテストは大きくなる E2Eテストは運用を続ければ必ず大きくなります。スプリントごとに要件が積み上がるのだからそれ自体は健全なことです。 問題はその大きくなり方。 Playwrightのデフォルト構成では、テストが増えるときに同じ記述——Locator、操作手順、待機、検証——がコピーで広がっていき、結果2つの状態に誘引されていきます。 変更追随性が下がる —— UIや手順のひとつの変更が、散らばった記述の数だけ同時に届く。1つの機能修正で変更箇所が各所にわたる。 レビュー性が下がる —— どこで何が使われているかが追いにくくなり、レビューが「コードの良し悪しの主観判断」になってしまう。 この2つが下がった先で起きやすいのが「Failしたテストの原因を調べるより、作り直したほうが早い」という判断です。 その判断は間違っていませんし、実際に正しい局面が多いのですが、問題は「その
PlaywrightではじめるE2Eテスト入門（後編） - ICS MEDIA
フロントエンド開発では、UIの挙動を含めてアプリ全体を検証するE2E（End-to-End）テストが重要になっています。しかし、導入や運用の難しさから、実践に踏み出せていない方もいるのではないでしょうか。 本記事では、前後編に分けて、シンプルなウェブアプリを題材に、Playwrightプレイライトを用いたE2Eテストの導入から活用までの流れを解説します。 前編では、Playwrightの導入方法やテストコードの基本的な書き方、テスト実行の流れについて紹介しました。後編となる今回は、失敗したテストの原因を特定するのに役立つトレース機能について解説します。さらに、CI環境でテストを自動実行する方法も紹介します。 本記事の対象読者 Playwrightの基本的な使い方を理解し、次のステップに進みたい方 Playwrightをチーム開発やCI環境に組み込みたいと考えている方 本記事のゴール トレー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
