読者です 読者をやめる 読者になる 読者になる

『Selenium 実践入門』読んだ

book

Selenium 大全と呼ぶにふさわしい一冊

Selenium WebDriver だけでなく、 Geb・FluentLenium・Capybara といったサポートライブラリや Selenium IDE、 さらには Appnium まで網羅している。

ページオブジェクトパターンや CI といったベストプラクティスもあり。

巻末には CSS セレクタや・XPATH・WebDriver API の早見表も載っていて、 リファレンスとしても使える。

本書のサンプルコードはほとんど Java

他の言語でも API はだいたい同じだし、 巻末の早見表もあるので無問題。

Selenium サポートライブラリに関しては、 こればっかりは使おうと思ったら言語も Groovy や JavaRuby を使うしかない。

ただ、E2E テストは何も Web サービスと同じ言語でないと書けないわけではないし。 Web サービスは C# だけど、E2E テストは Ruby というのも全然アリ。

E2E テストでテストデータ投入とクリーンアップ

Selenium 使った E2E テストでは、どうすればいいんだろうね。

単体テストなら、テストメソッド実行前にトランザクション開始してからテストデータ投入して、 テスト後にロールバックする手が使えた。

E2E テストの場合、実際の登録用 API を使うという手法がさらっと紹介されていた。 あまりオススメではないみたいだけど、テスト専用 API を作るという手もある。

Rails のときはトランザクション使わずに、 ActiveRecord でデータ投入して database-cleaner でクリーンアップしていたけど、 JavaC# でも同様の仕組みが要るのかもな。

サイボウズDeNA の事例も載っている

どちらも E2E テストの数が増えて、すべて実行するのに非常に時間がかかる問題に直面していた。 どちらも並列化で対応していたけど、サイボウズSelenium Grid、DeNA は Jenkins のマスター/スレーブと、 アプローチが異なっていて参考になる。

本書にも書いてあるけど、E2E テストは単体テストと比べて時間がかかるので、 ユーザーシナリオに重点を置いたテストをやるのが現実的。 重箱の隅は単体テストでつつくのがベターか。

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)