2016/07/22

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

ブラウザテストツールとして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 によるデータ駆動テスト

索引


0 件のコメント :

コメントを投稿

Comments on Google+: