"入門"WebフロントエンドE2Eテスト―PlaywrightによるWebアプリの自動テストから良いテストの書き方まで(エンジニア選書) [単行本]

"入門"WebフロントエンドE2Eテスト―PlaywrightによるWebアプリの自動テストから良いテストの書き方まで(エンジニア選書) の 商品概要

• 要旨（「BOOK」データベースより）

  Ｅ２Ｅテスト（Ｅｎｄ‐ｔｏ‐Ｅｎｄ　Ｔｅｓｔｉｎｇ）とは、システムの端から端（Ｅｎｄ‐ｔｏ‐Ｅｎｄ）まで、全体を通して行うソフトウェアテストを指します。本書ではＥ２Ｅテストを「ユーザーの視点でＷｅｂシステムの動作を確認する自動テスト」として定義し、Ｅ２Ｅテストをこれからプロジェクトに導入しようとしている人、すでに導入しているがパフォーマンスや保守性で課題を感じている人を対象に、Ｅ２Ｅテストのフレームワークとして近年人気が急上昇しているＰｌａｙｗｒｉｇｈｔをツールとして、その目的からモダンなノウハウまで、Ｅ２Ｅテスト初心者の方にもわかりやすくハンズオンを交えながら解説します。ＣＩへ組み込む方法やユニットテストとの棲み分けなど、Ｅ２Ｅテストを実際の開発現場に投入するうえでの知見も数多く紹介します。

• 目次

  ■■■第1章　Playwrightハンズオン
  ■■1.1　Playwrightのセットアップ方法
  ■1.1.1　インストールと初期設定
  ■1.1.2　Playwrightのディレクトリ構成
  ■■1.2　テスト用Webアプリケーションの作成
  ■1.2.1　Playwrightの導入
  ■■1.3　表示のテストとテストの実行方法
  ■1.3.1　新規ページの作成
  ■1.3.2　最初のテスト
  ■1.3.3　テストの実行
  ■■1.4　ページ遷移のテストとテスト生成機能
  ■1.4.1　フォーム入力のテストを生成する
  ■■1.5　フォーム操作のテスト
  ■■1.6　まとめ
  ■■■第2章　E2Eテストツールの紹介
  ■■2.1　E2Eテストツールの歴史
  ■■2.2　ブラウザベースのE2Eテストツール
  ■2.2.1　Cypress
  ■2.2.2　Puppeteer
  ■2.2.3　Playwright
  ■2.2.4　E2Eテストツールの比較
  ■■2.3　WebフロントエンドフレームワークとE2Eテストツール
  ■2.3.1　Svelte
  ■2.3.2　Vue.js
  ■2.3.3　React
  ■2.3.4　Angular
  ■2.3.5　Electron
  ■■2.4　まとめ
  ■■■第3章　Playwrightのテスト用ツールセット（1）ロケーター
  ■■3.1　テストツールのカテゴリ
  ■［column］アサーションとPlaywright
  ■■3.2　ロケーター
  ■3.2.1　getByRole()
  ■3.2.2　getByLabel()
  ■3.2.3　getByPlaceholder()
  ■3.2.4　getByText()
  ■3.2.5　getByAltText()
  ■3.2.6　getByTitle()
  ■3.2.7　getByTestId()
  ■［column］data-testidはいつ使うべきか？
  ■3.2.8　その他のロケーター
  ■■3.3　壊れにくいテスト
  ■3.3.1　ラベルやプレースホルダーのみによる要素取得
  ■3.3.2　適切なラベルの付け方
  ■■3.4　getByRole()で指定可能なロール
  ■3.4.1　テストで頻繁に利用するロール
  ■3.4.2　テストでの利用頻度が低いと思われるロール
  ■■3.5　高度なロケーター
  ■3.5.1　フィルター
  ■3.5.2　一度絞り込んだ要素の中からさらに検索
  ■3.5.3　複数の要素の絞り込み
  ■3.5.4　その他のロケーター
  ■3.5.5　複数要素のあるリストやテーブルからの情報取得
  ■■3.6　まとめ
  ■■■第4章　Playwrightのテスト用ツールセット（2）ナビゲーション、アクション、マッチャー
  ■■4.1　ナビゲーション
  ■4.1.1　goto()
  ■4.1.2　waitForURL()
  ■4.1.3　toHaveTitle()とtoHaveURL()
  ■■4.2　アクション
  ■4.2.1　アクション可能性
  ■4.2.2　キーボード操作：fill()/clear()/press()/pressSequentially()
  ■4.2.3　チェックボックスやラジオボタンのチェック：check()/uncheck()
  ■4.2.4　セレクトボックスの選択：selectOption()
  ■4.2.5　マウス操作：click()/dblclick()/hover()/dragTo()
  ■4.2.6　フォーカス：focus()
  ■4.2.7　ファイルのアップロード：setInputFiles()
  ■■4.3　マッチャー
  ■4.3.1　toContainText()/toHaveText()/toBeVisible()/toBeAttached()
  ■4.3.2　not
  ■4.3.3　toBeChecked()
  ■4.3.4　toBeDisabled()とtoBeEnabled()
  ■4.3.5　toBeEmpty()とtoBeHidden()
  ■4.3.6　toBeFocused()
  ■4.3.7　toHaveCount()
  ■4.3.8　toHaveValue()とtoHaveValues()
  ■4.3.9　その他のマッチャー
  ■■4.4　リトライの挙動
  ■4.4.1　リトライのタイムアウト
  ■4.4.2　固定時間を待つコードはやめよう
  ■■4.5　まとめ
  ■■■第5章　テストコードの組み立て方
  ■■5.1　何をテストとするか？
  ■5.1.1　テストの分類とPlaywrightができること
  ■5.1.2　テストのボリュームのパターン
  ■5.1.3　最初の一歩：一筆書き
  ■■5.2　テストコードを書く
  ■5.2.1　test()
  ■5.2.2　テストのグループ化
  ■［column］ビヘイビア駆動開発（BDD）の用語
  ■5.2.3　準備・片付けコードを共有する
  ■5.2.4　すばやく繰り返す
  ■■5.3　テストのコメントを書くべきか
  ■■5.4　テストファイルの命名
  ■■5.5　ビジュアルリグレッションテスト
  ■■5.6　まとめ
  ■■■第6章　実践的なテクニック
  ■■6.1　スクリーンショットとビデオ
  ■6.1.1　スクリーンショットの撮影
  ■6.1.2　ビデオの撮影
  ■■6.2　認証を伴うテスト
  ■6.2.1　認証を使わないモードを実装する
  ■6.2.2　セッション情報を共有する
  ■■6.3　ネットワークの監視とハンドリング
  ■6.3.1　ネットワークの監視
  ■6.3.2　ネットワークのハンドリング
  ■■6.4　複数ブラウザでの動作確認
  ■6.4.1　ブラウザの基礎知識
  ■6.4.2　Playwrightのサポートブラウザ
  ■6.4.3　ブラウザのインストール
  ■6.4.4　ブラウザの設定
  ■6.4.5　複数ブラウザのテストを実行
  ■6.4.6　ブラウザのエミュレーション
  ■［column］Playwright Test for VSCodeで実行するブラウザを指定するには129
  ■［column］設定のスコープ
  ■■6.5　まとめ
  ■■■第7章　ソフトウェアテストに向き合う心構え
  ■■7.1　テストの7原則
  ■■7.2　ソフトウェアテストの構成要素
  ■7.2.1　テストレベル
  ■7.2.2　テストタイプ
  ■［column］確認テストとリグレッションテスト
  ■7.2.3　テスト技法
  ■［column］テスト技法を理解すると設計力も上がる
  ■■7.3　コード品質とは何か？
  ■■7.4　E2Eテストとユニットテストの効率の良い棲み分け
  ■［column］パラメータ化テスト
  ■■7.5　テストコードの設計方針とリファクタリング
  ■7.5.1　テストは単独で実行できるようにする
  ■7.5.2　テストは単独で読めるようにする
  ■7.5.3　壊れにくいテストにする
  ■■7.6　モックとの付き合い方
  ■■7.7　E2Eテストの投資対効果を上げる
  ■［column］テスト自動化の8原則
  ■■7.8　まとめ
  ■■■第8章　E2Eの枠を超えたPlaywrightの応用例
  ■■8.1　ランダムテスト
  ■8.1.1　ランダムにリンクをクリックするテスト
  ■■8.2　コンポーネントのテスト
  ■8.2.1　インストール
  ■8.2.2　コンポーネントに対するテストのメリット／デメリット
  ■8.2.3　コンポーネントに対するテストのサンプル
  ■8.2.4　コンポーネントに対するビジュアルリグレッションテスト
  ■■8.3　再利用可能性
  ■8.3.1　テストの流れを把握しやすくする
  ■8.3.2　テストを書きにくい画面に気づいたとき
  ■■8.4　テストの並列実行
  ■8.4.1　並列実行におけるPlaywrightの仕様
  ■8.4.2　並列にテストを実行しないようにする
  ■8.4.3　並列にテストを実行する際の注意
  ■■8.5　まとめ
  ■■■第9章　Web APIのテスト
  ■■9.1　PlaywrightにおけるWeb APIテスト
  ■■9.2　テストの実行例
  ■■9.3　タイムトラベルデバッグ
  ■■9.4　より詳細なテスト方法
  ■9.4.1　メソッド
  ■9.4.2　ヘッダとクエリの送信
  ■9.4.3　ボディの送信
  ■■9.5　通常のE2Eテストの中からWeb APIを呼び出す
  ■■9.6　まとめ
  ■■■第10章　E2Eテストの実戦投入
  ■■10.1　どのテストから書き始めるか
  ■10.1.1　人力テストからE2Eテストへ移行する
  ■10.1.2　テストシナリオを洗い出してからE2Eテストを書く
  ■10.1.3　ユニットテストから書き始める
  ■■10.2　E2Eテストをどのリポジトリに置くか
  ■10.2.1　E2Eテスト専用リポジトリ
  ■10.2.2　フロントエンドのリポジトリとの相乗り
  ■■10.3　CIでのE2Eテスト実行
  ■10.3.1　GitHub ActionsでPlaywrightのE2Eテストを実行
  ■10.3.2　CI実行結果のレポートを確認
  ■10.3.3　CI実行時間の短縮
  ■■10.4　プロジェクト管理との統合
  ■10.4.1　テストのプロジェクト管理
  ■10.4.2　自動テストとの統合
  ■■10.5　まとめ
  ■■■第11章　Playwrightの内部構造
  ■■11.1　Playwrightのアーキテクチャ
  ■■11.2　他のE2Eテストツールのアーキテクチャ
  ■11.2.1　Cypressのアーキテクチャ
  ■11.2.2　Seleniumのアーキテクチャ
  ■■11.3　クライアント／サーバ構成でのテスト実行
  ■11.3.1　サーバの起動
  ■11.3.2　接続先サーバの指定
  ■11.3.3　テストの実行
  ■11.3.4　使いどころ
  ■■11.4　まとめ
  ■■■付録
  ■■付録A　生成AIによるテストコードの自動生成
  ■A.1　テストの作成
  ■A.2　テストデータの作成
  ■A.3　テストケースの作成
  ■■付録B　VSCode Dev Containersを利用した環境構築
  ■B.1　VSCode Dev Containersとは
  ■B.2　セットアップ手順
  ■B.3　PlaywrightのUIモード実行
  ■■付録C　ユニットテストフレームワークとの共存
  ■C.1　Jestとの共存
  ■C.2　Vitestとの共存
  ■■付録D　Playwrightを使ったスクレイピング
  ■D.1　スクレイピングを行う際の注意
  ■D.2　プロジェクトの作成とひな形のコード生成
  ■D.3　構造の修正とコマンドライン引数のパース
  ■D.4　都道府県情報のパース
  ■D.5　週間天気のパース
  ■■付録E　Microsoft Playwright Testing
  ■E.1　Microsoft Playwright Testingを試す
  ■E.2　ワークスペースを作成する
  ■E.3　テスト環境を設定する
  ■E.4　テストを実行する

• 内容紹介

  E2Eテスト（End-to-End Testing）とは、システムの端から端（End-to-End）まで、全体を通して行うソフトウェアテストを指します。本書ではE2Eテストを「ユーザーの視点でWebシステムの動作を確認する自動テスト」として定義し、E2Eテストをこれからプロジェクトに導入しようとしている人、すでに導入しているがパフォーマンスや保守性で課題を感じている人を対象に、E2Eテストのフレームワークとして近年人気が急上昇しているPlaywrightをツールとして、その目的からモダンなノウハウまで、E2Eテスト初心者の方にもわかりやすくハンズオンを交えながら解説します。CIへ組み込む方法やユニットテストとの棲み分けなど、E2Eテストを実際の開発現場に投入するうえでの知見も数多く紹介します。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  渋川 よしき(シブカワ ヨシキ)
  フューチャーアーキテクト株式会社Ｔｅｃｈｎｏｌｏｇｙ　Ｉｎｎｏｖａｔｉｏｎ　Ｇｒｏｕｐ。自動車会社、ソーシャルゲームの会社を経て現職。Ｐｙｔｈｏｎ／Ｃ＋＋／ＪａｖａＳｃｒｉｐｔ／Ｇｏｌａｎｇあたりを仕事や趣味で扱う
  
  武田 大輝(タケダ ヒロキ)
  フューチャーアーキテクト株式会社Ｔｅｃｈｎｏｌｏｇｙ　Ｉｎｎｏｖａｔｉｏｎ　Ｇｒｏｕｐ。アーキテクチャデザインからデリバリーまでを担うソフトウェアアーキテクト兼テックリード。機能・非機能のトータルバランスを意識した全体設計を行い、自らの手で多くのシステムを構築してきた。Ｇｏを用いたバックエンド開発、Ｖｕｅ．ｊｓを用いたフロントエンド開発が得意
  
  枇榔 晃裕(ビロウ アキヒロ)
  フューチャー株式会社サイバーセキュリティイノベーショングループ。フロントエンドエンジニア。Ｒｅａｃｔ．ｊｓを用いたフロントエンド開発が得意。ヒトとテクノロジのやりとりに関心を持ち、直感的に理解できるシステムを目指して開発を行っている
  
  木戸 俊輔(キド シュンスケ)
  フューチャー株式会社サイバーセキュリティイノベーショングループ。踊るエンジニア。ＳａａＳ開発・運営を中心にキャリアを積んできた。公私で開発を楽しむ傍ら、品質保証やシステムテストにも興味を持ち、執筆活動にも取り組む
  
  藤戸 四恩(フジト シオン)
  フューチャーアーキテクト株式会社流通製造グループ。機械学習が得意
  
  小澤 泰河(オザワ タイガ)
  フユーチャーアーキテクト株式会社。Ｔｅｃｈｎｏｌｏｇｙ　Ｉｎｎｏｖａｔｉｏｎ　Ｇｒｏｕｐ。おもにＢ２Ｂの業務システムについて、Ｗｅｂアプリケーションの開発、顧客折衝を通したアーキテクチャの検討などを行っている。Ｗｅｂフロントエンド、ＵＩ／ＵＸ、ビジネス形態と開発形態の関係性に興味を持つ

• 著者について

  渋川 よしき (シブカワ ヨシキ)
  フューチャーアーキテクト株式会社　Technology Innovation Group自動車会社、ソーシャルゲームの会社を経て現職。Python/C++/JavaScript/Golangあたりを仕事や趣味で扱う。Web関連は仕事よりも趣味寄り。著書に『Goならわかるシステムプログラミング』（ラムダノート）、『Real World HTTP 第3版』（オライリー・ジャパン）、共著に『実用Go言語』（オライリー・ジャパン）、『つまみぐい勉強法』（技術評論社）、訳書に『アート・オブ・コミュニティ』『ソフトウェア設計のトレードオフと誤り』（ともにオライリー・ジャパン）、共訳に『エキスパートPythonプログラミング改訂4版』（アスキードワンゴ）など。X：shibu_jp
  
  武田 大輝 (タケダ ヒロキ)
  フューチャーアーキテクト株式会社　Technology Innovation Groupアーキテクチャデザインからデリバリーまでを担うソフトウェアアーキテクト兼テックリード。機能・非機能のトータルバランスを意識した全体設計を行い、自らの手で多くのシステムを構築してきた。Goを用いたバックエンド開発、Vue.jsを用いたフロントエンド開発が得意。コードを書いているときが一番幸せ。X：@rhumie_
  
  枇榔 晃裕 (ビロウ アキヒロ)
  フューチャー株式会社　サイバーセキュリティイノベーショングループフロントエンドエンジニア。React.jsを用いたフロントエンド開発が得意。ヒトとテクノロジのやりとりに関心を持ち、直感的に理解できるシステムを目指して開発を行っている。X：@alfe_below
  
  木戸 俊輔 (キド シュンスケ)
  フューチャー株式会社　サイバーセキュリティイノベーショングループ踊るエンジニア。SaaS開発・運営を中心にキャリアを積んできた。公私で開発を楽しむ傍ら、品質保証やシステムテストにも興味を持ち、執筆活動にも取り組む。X：@kidokidofire_
  
  藤戸 四恩 (フジト シオン)
  フューチャーアーキテクト株式会社　流通製造グループ機械学習が得意。最近はGoやReact.tsを使ってコードを書くことが好き。X：@fujito_shion
  
  小澤 泰河 (オザワ タイガ)
  フューチャーアーキテクト株式会社　Technology Innovation GroupおもにB2Bの業務システムについて、Webアプリケーションの開発、顧客折衝を通したアーキテクチャの検討などを行っている。Webフロントエンド、UI/UX、ビジネス形態と開発形態の関係性に興味を持つ。X：@taigaozawa

"入門"WebフロントエンドE2Eテスト―PlaywrightによるWebアプリの自動テストから良いテストの書き方まで(エンジニア選書) の商品スペック