ページオブジェクトパターンでブラウザテストを書け!Seleniumデザインパターン&ベストプラクティスを読んで

2016/07/22

selenium テスト

t f B! P L
記事内に広告が含まれています。

ブラウザテストツールとしてSeleniumが知られるようになってきて、3冊ほど本が出た。そのうち、O'Reillyから出ているSeleniumデザインパターン & ベストプラクティスを読んでみた。

概要

1章
Selenium IDEは結局使わない。1.6からが本番。本書ではテストをRubyで書いている。テストのフレームワークはTest::Unitを使っている。
2章
テストコードでありがちな問題。
3章
テストをリファクタリングしてみる。
4章
テスト用のデータをテストコードから分離する。
5章
テストの安定化。Webシステム特有の問題に対処する。
6章
ブラウザテストとは。ブラウザに表示されるか?クリックしたらどの画面に遷移するか?といった振る舞いのテストである。
7章
テストをPage Objectパターンに書き換える。
8章
テストを保守し、どういった方針で充実させていくか。

ブラウザテストはぺージオブジェクトパターンで作る

Seleniumは言語に依存しないため、各言語から使いやすくするためのバインディングが用意されている。使い方がシンプル(Seleniumの薄っすい話4:俺と非公式バインディング - Qiitaが分かりやすい)なため、非公式なバインディングを含め、様々な言語のバインディングが作られている。
ブラウザテストは振る舞いテストなので、テスト対象と同じ言語でテストを書く必要はない。だから、書きやすいと思う言語で書けば良い。

本書はRubytest::unitでテストを書いているが、他の言語で役に立たないということはない。むしろ、ページオブジェクトパターンの重要性の説明が本当の目的ではないか?
ただ、ページオブジェクトパターンでやろうとする事はどんなWebシステムのテストコードでもやることなので、本書のように一から作るのではなく、SitePrismのようなライブラリを使う方が効率的だろう。SitePrismに関する日本語の記事はあまり見かけないが、例えばSitePrismを使ってSelenium+Capybaraのテストをぺージオブジェクトパターンで書くなどがある。

目次より

目次
まえがき
監訳者まえがき
はじめに

1章 最初のテストを書く
    1.1 Selenium を選択する
        1.1.1 適材適所
        1.1.2 価格
        1.1.3 オープンソース
        1.1.4 柔軟性
    1.2 Record and Playback パターン
        1.2.1 Record and Playback パターンの利点
        1.2.2 Record and Playback パターンの欠点
    1.3 Selenium IDE に取り掛かる
        1.3.1 Selenium IDE のインストール
        1.3.2 最初のテストを記録する
        1.3.3 テストを保存する
    1.4 Selenium コマンドを理解する
        1.4.1 Selenese を読む
    1.5 Ruby とSelenese を比較する
        1.5.1 Selenium コマンドをさまざまな言語と比較する
    1.6 Selenium テストをRuby で書く
        1.6.1 Test::Unit を導入する
        1.6.2 アサートを導入する
        1.6.3 テストをインタラクティブにデバッグする
    1.7  まとめ

2章 Spaghetti パターン
    2.1 Spaghetti パターン
        2.1.1 Spaghetti パターンの利点
        2.1.2 Spaghetti パターンの欠点
    2.2 商品レビュー機能をテストする
        2.2.1 商品レビューテストに取り掛かる
        2.2.2 ページ上の要素を指定する
        2.2.3 ロケータ
        2.2.4 ロケータのコードを書く
        2.2.5 クリックとアサーションを実装する
        2.2.6 レビュー重複テスト
    2.3 失敗の理由
    2.4 Chain Linked パターン
    2.5 Big Ball of Mud パターン
    2.6 まとめ

3章 テストをリファクタリングする
    3.1 テストをリファクタリングする
    3.2 DRY テストパターン
        3.2.1 DRY テストパターンの利点
        3.2.2 DRY テストパターンの欠点
    3.3 Hermetic テストパターン1
        3.3.1 Hermetic テストパターンの利点
        3.3.2 Hermetic テストパターンの欠点
        3.3.3 テスト同士の依存関係を取り除く
    3.4 汎用的なDRY メソッドを作る
        3.4.1 汎用的なメソッドを使ってリファクタリングする
    3.5 ランダム実行順序原則
        3.5.1 ランダム実行順序原則の利点
        3.5.2 ランダム実行順序原則の欠点
    3.6 まとめ

4章 データ駆動テスト
    4.1 データの妥当性とアクセシビリティ
    4.2 入力データをハードコーディングする
        4.2.1 テストデータをテストから隠蔽する
    4.3 テストフィクスチャ
        4.3.1 フィクスチャデータをパースする
        4.3.2 テストにフィクスチャデータを使う
    4.4 API をフィクスチャデータのソースとして使う
    4.5 データスタブを使う
    4.6 Default Values パターン
        4.6.1 Default Values パターンの利点
        4.6.2 Default Values パターンの欠点
        4.6.3 Default Values パターンとfaker ライブラリを融合させる
    4.7 まとめ

5章 テストを安定させる
    5.1 安定を保つ文化カルチャを築く
        5.1.1 すばやく実行し、すばやく失敗させる
        5.1.2 できる限り頻繁に実行する
        5.1.3 クリーンで一貫性のある環境を保つ
        5.1.4 間違ったコード変更を捨てる
        5.1.5 安定したテストスイートを維持する
    5.2 Ajax を待つ
        5.2.1 Ajax 遅延なしにテストする
        5.2.2 明示的な遅延を使ってAjax フォームをテストする
    5.3 JavaScript アニメーションを待つ
    5.4 Action Wrapper パターン
        5.4.1 Action Wrapper パターンの利点
        5.4.2 Action Wrapper パターンの欠点
        5.4.3 Action Wrapper パターンを実装する
    5.5 Black Hole Proxy パターン
        5.5.1 Black Hole Proxy パターンの利点
        5.5.2 Black Hole Proxy パターンの欠点
        5.5.3 Black Hole Proxy パターンを実装する
    5.6 テストをテストしよう
    5.7 まとめ

6章 振る舞いをテストする
    6.1 振る舞い駆動開発
        6.1.1 BDD の利点
        6.1.2 BDD の欠点
    6.2 ショッピングカートの振る舞いをテストする
        6.2.1 ショッピングカートの振る舞いを記述する
        6.2.2 ステップ定義を書く
        6.2.3 BDD は自分のプロジェクトにふさわしいか?
    6.3 Cucumber
        6.3.1 フィーチャファイル
        6.3.2 ステップ定義ファイル
        6.3.3 config ディレクトリ
    6.4 Cucumber スイートを実行する
    6.5 Write Once, Test Everywhere パターン
        6.5.1 Write Once, Test Everywhere パターンの利点
        6.5.2 Write Once, Test Everywhere パターンの欠点
    6.6 モバイルサイトをテストする
        6.6.1 Selenium ラッパを更新する
        6.6.2 購入API をテストする
    6.7 まとめ

7章 Page Object パターン
    7.1 オブジェクトを理解する
        7.1.1 オブジェクトを文字で表現する
        7.1.2 プログラムでオブジェクトを表現する
        7.1.3 オブジェクトを使ってウェブページを表現する
    7.2 Page Object パターン
        7.2.1 Page Object パターンの利点
        7.2.2 Page Object パターンの欠点
    7.3 Page Object フレームワークを作る
        7.3.1 Page スーパークラスを作る
        7.3.2 サイドバーオブジェクトを実装する
        7.3.3 ページに自己検証を追加する
        7.3.4 個々のページクラスを実装する
        7.3.5 ウェブサイトの成長に合わせて、サイドバーオブジェクトを増やす
    7.4 Page Object フレームワークを使ってテストを実行する
        7.4.1 Test::Unit フレームワークでPage Object を使う
        7.4.2 別のテストフレームワークでPage Object を使う
    7.5 Test Tool Independence パターン
        7.5.1 Test Tool Independence パターンの利点
        7.5.2 Test Tool Independence パターンの欠点
    7.6 Page Object の正しい実装方法
        7.6.1 テストよりもページを賢くする
        7.6.2 ページよりもテストを賢くする
        7.6.3 継承の代わりにモジュールを使う
        7.6.4 Page Object にロジックを置く
    7.7 まとめ

8章 テストスイートを成長させる
    8.1 テストスイートを書くための戦略
        8.1.1 さまざまなタイプのテスト
        8.1.2 スモークテストスイート
        8.1.3 マネーパススイート
        8.1.4 新機能戦略
        8.1.5 バグ駆動戦略
        8.1.6 リグレッションスイート
        8.1.7 99% カバレッジスイート
    8.2 継続的インテグレーション
        8.2.1 テスト環境とテストノードを管理する
        8.2.2 Selenium Grid
        8.2.3 CI ツールを選ぶ
    8.3 FAQ
        8.3.1 どうやって複数のブラウザでテストするのですか?
        8.3.2 どのプログラミング言語でテストを書けば良いですか?
        8.3.3 Selenium を使ってJS 機能をテストすべきでしょうか?
        8.3.4 なぜヘッドレスブラウザを使うべきなのですか?
        8.3.5 私のチームではどのBDD ツールを使うべきでしょうか?
        8.3.6 パフォーマンステストにSelenium を使えますか?
    8.4 まとめ

付録A Selenium をはじめよう
    A.1 コンピュータをセットアップする
        A.1.1 コマンドラインインターフェイスを使う
    A.2 Ruby ランタイム環境を設定する
        A.2.1 Ruby をインストールする
        A.2.2 Firefox をインストールする
    A.3 テストクラスの命名規則を理解する
        A.3.1 ファイルを命名する
        A.3.2 クラスを命名する
        A.3.3 名前空間を理解する
        A.3.4 オブジェクト継承を示す
    A.4 まとめ

付録B Test::Unit によるデータ駆動テスト

索引
楽天で探す
楽天市場
にほんブログ村 IT技術ブログへ

人気の投稿

ブログ アーカイブ

自己紹介

パワハラをなぁなぁで済まそうとする奴がCxOやっている会社を辞めました。ストックオプションは半分しか行使できなかったけど、あんな人たちには関わりたくないですね。

アフィリエイト

  • 当ブログ「Hiroaki's blog」は、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、Amazonアソシエイト・プログラムの参加者です。
  • 当ブログでは、第三者配信による広告サービスを利用しています。このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 (氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。このプロセスの詳細やこのような情報が広告配信事業者に使用されないようにする方法については、ここをクリックしてください。
  • アクセストレードアフィリエイトプログラムに参加しています。
  • A8.netアフィリエイトプログラムに参加しています。
  • バリューコマースアフィリエイトプログラムに参加しています。
  • もしもアフィリエイトプログラムに参加しています。

プライバシーポリシー

当サイトにアクセスされる場合、IPアドレスなどの情報または閲覧状況に関するデータが機械的に生成され、場合によっては個人情報と関連付けられる可能性があります。プライバシー保護に関する適用法に準じて、これらの通信および閲覧に関するデータを収集、処理、および利用することがあります。
当サイトにアクセスされる場合、非個人情報(ブラウザの種類、OSの種類、ドメイン名、訪問数、平均滞在時間、ページ・ビューなど個人を特定できない情報)が自動収集される場合があります。当サイトのパフォーマンスやコンテンツを改善する目的で、これらの情報を利用する場合があります。
アフィリエイトでは成果を把握するためにcookie等を利用しています。それ以外の目的で使用されることはありません。詳しくは各社のページにて確認してください。
本サイトに掲載する情報に関しては、正しいものを提供することを務めていますが、掲載内容から、いかなる損失や損害などの被害が発生しても、当ブログでは責任を追いかねます。

改正電気通信事業法に関する表記

・掲載内容

当サイトでは成果報酬型広告/クリック型広告の効果測定のため、利用者の方のアクセス情報を外部事業者に送信しております。
当該の情報は個人を特定する情報ではございません。また当該の情報が目的外利用される事は一切御座いません。

1.送信される情報の内容
  • 広告の表示日時
  • 広告のクリック日時
  • 広告の計測に必要なクッキー情報
  • 広告表示時及び広告クリック時のIPアドレス
  • 広告表示時及び広告クリック時に使用されたインターネット端末およびインターネットブラウザの種類
2.送信先となる事業者の氏名又は名称
  • グーグル合同会社
  • 楽天グループ株式会社
  • アマゾンジャパン合同会社
  • ヤフー株式会社
  • 株式会社ファンコミュニケーションズ
  • 株式会社もしも
3.利用目的

成果報酬型広告/クリック型広告の効果測定および不正防止のため

QooQ