WebDriverで画面テストを作るときに壮絶に参考になった資料やブログ

WebDriverを使った画面テスト自動化の事例がだいぶ増えてきたので、参考になった資料やブログをまとめてみます。

シャノンの井上さんの発表資料

WebDriverを使っているとわかってくるのが画面テスト自動化が不安定だということ。The official Sauce Labs BlogのHow to Lose Races and Win at Seleniumの引用にもあるように、処理が早すぎてページのロードを待たずに次に進んでしまうことも原因の一つとしてあげられます。

テスト安定のためSeleniumIDEからWebDriverに変更し、検証するメソッドの中に待ち時間を設定する作戦を実装することで対応可能。僕もこれを参考に検証メソッドにWebDriverにあるWaitを使ってみたのですが、かなり安定するようになりました。

次に、実行時間の問題について。ブラウザを起動するコストがかかるのでどうしても画面テストに時間がかかってしまいます。JenkinsのGrid機能を使うことで時間を短縮させた軌跡がとても素晴らしい。やっぱ、「使い方の説明」よりも「改善の道のり」は面白い！

デブサミ関西での事例

デブサミ関西での発表資料。TestNGとWebDriverの組み合わせ。

なんでTestNGを使ったか？というところが興味深くて、僕の環境でもテストが増えてくると、テストのグループ化とかやっぱり考えなければならなくなりました。僕の場合はRakefileでテストケースを分類しているけど、こういう仕組みがテスティングフレームワークにあると便利ですね。

うなの日記さんのブログが壮絶に参考になる

うなの日記さんの[雑記] Seleniumを使ったWeb UI自動テストシステムの構築でやったことまとめはものすごく参考になります。自動画面テストを作る時の注意点がまとめれており、自分がぶつかった壁もいくつかありました。

ページオブジェクトパターンの採用はまずぶつかった壁で、当初はどこまで抽象化したらいいかわからなかったので、主要機能のみ抽象化し、抽象化されていない部分も半分ぐらいありました。しかし、画面修正時になって修正コストがかさむことがわかったので、ブログの例のようにXPathを使う層を新たに作りリファクタリングを「うぉー」っとすることになったのが懐かしい。

また、ムダなテストは作らないのも納得。メンテナンスコストがまったく予想できなかったので、「大変になったら捨てよう」を合言葉に画面テストを書いていました。まだそういう領域にはたどり着いていないですが、大幅なデザイン変更など、Webサービスでよくあるイベントが来た時に備えて、この考えを忘れずにテストしていこうと思っています。

まとめ

プログラムが作りやすい時代になったのはいいのですが、それに伴いテストのコストも増えるジレンマがあります。私の経験上では、テストのコストは無視されることが多い。また、レガシーコード（テストのないコード）のほうが世の中多いんじゃないかと思うのです。今だにそういうコードが作り続けられているみたいですよね。

Webを使ったサービスの場合、行き着く先がブラウザなので、テストコストの削減や、レガシーコードの改善に、画面テストの自動化が役に立つんじゃないかなぁと思い、まさに今、壮大な実験＆Tryをしています。

そういったわけで、今回紹介させていただいた資料やブログがとても役に立ちました。得た経験が共有され、また共有される。あらためて、Webっていいなぁとも思いました。