Hatena::Groupdann

dann's blog このページをアンテナに追加 RSSフィード

Fork me on GitHub

2008-07-12

SeleniumRCでTestSuiteを実行

| SeleniumRCでTestSuiteを実行 - dann's blog を含むブックマーク はてなブックマーク - SeleniumRCでTestSuiteを実行 - dann's blog SeleniumRCでTestSuiteを実行 - dann's blog のブックマークコメント

SeleniumRCを使うケースだと定期的にTestSuiteを実行させたいなぁっていうのがあるんじゃないかと思います。以下のようなスクリプトをCRONで1日単位でまわして朝見るってだけでも、ユースケースレベルのテストを確認するのには使えます。


#!/bin/sh
BROWSER=*safari
BASE_URL=http://www.google.co.jp
TEST_SUITE=/Users/dann/workdir/cattest/MyApp/t/acceptance.html
TEST_RESULT=/Users/dann/workdir/cattest/MyApp/t/acceptance_result.html
java -jar selenium-server.jar -htmlSuite "$BROWSER" "$BASE_URL" "$TEST_SUITE" "$TEST_RESULT" -timeout 60000

複数ブラウザでテストするのも上記のスクリプトをちょっと書き換えれば簡単にできますね。テストサーバーがあって、バックエンドでテストを実行させておきたいというのは割とよくあるケースで、上記のような簡単なスクリプトでも十分実用で使えます。

subverionからテストケースをcheckoutして、testsuiteをtestcaseから自動生成してから、上記のスクリプトでテストを実行させるなんて使い方がいいでしょうね。testsuiteの生成などについては、以前エントリを書いたので参考にしてみてください。

他にも、Selenium AESといった、似たようなことができるものもあるようなので、会社としてやりたい場合には、もうちょっと凝った仕組みを用意してもいいかもしれあないですね。

http://www.enjoyxstudy.com/selenium/autoexec/

SeleniumのGoog/Badから考えるアクセプタンステスト

| SeleniumのGoog/Badから考えるアクセプタンステスト - dann's blog を含むブックマーク はてなブックマーク - SeleniumのGoog/Badから考えるアクセプタンステスト - dann's blog SeleniumのGoog/Badから考えるアクセプタンステスト - dann's blog のブックマークコメント

Seleniumは使いこなすと非常に強力なテストツールですが、向き不向きもあり、テスト用途によって、どのようなテストをどのようなタイミングで実行すべきかを変えた方がよくあります。そこで、SeleniumのGood/Bad、Seleniumのテストの用途、Seleniumのテストを書くべきタイミング、注意点についてまとめました。

今、何のテストを書いているのかを意識し、それに応じてテスト方法とテスト計画を変える事は、アプリケーションをテストする上でとても役に立つのではないかと思います。

では、それぞれ見ていきましょう。

SeleniumのGood/Bad

SeleniumのGoogな点
  • Cross browser testingが簡単
    • browserの指定だけすれば同じTest Suiteで複数のブラウザをテストする事ができます。これはSeleniumを使う事の最大のメリットです。
  • テストケース作成のコストが低い
    • SeleniumIDEがあるために、テスト生成が極めて簡単でテスト作成のとてもコストが小さくなっています
SeleniumのBadな点
  • Selenium RC serverが不安定
    • 途中で落ちるCI用途では全然使えない
    • そもそもbrowserが落ちることも...
  • ブラウザを使ったテストはとても遅いので、テストに時間がかかりすぎる
    • コミットの度に動かすにはあまりに時間がかかりすぎる

このことから、早くコミットの度に何度も実行するようなテストケースを作るという用途では殆ど使えません。少しテストスイートが大きくなると、割と早い段階で問題に気づく事になります。


Seleniumのアクセプタンステストの用途

Good/Badな点を考慮すると、用途は大きく分けて二つになります

  • Cross Broserのためのテスト
  • ユースケース毎のシナリオ

ユースケース単位で書きたいものと、Cross Browser用のテストがしたい部分はテストの粒度もかなり変わるので、Test Suiteも分けたほうがよいです。

Seleniumでのアクセプタンステストを書き出すタイミング

Cross Browserテスト

これはUIの要素の構造が決まれば書き始めたほうがいいです。Cross Browser系のテストはデグレードしたときに、早い段階でSeleniumRCでテストした方が最終的なコストは低くなります。

ただ、この部分のテストについても基本はJavaScript側での単体テストを中心とすべき内容で、JSのモジュール全体の結合テストとしての役割のほうが強くなります。

この目的のテストでは、Selenium以上に適したツールは今のところありません。基本はこちらを重点的にテストする目的でSeleniumを使った方が幸せになれます

ユースケースのシナリオテスト

バックエンドのアプリケーションがあるシナリオで動くという条件があり、かつUIの「構造」がある程度固まってきたタイミングで書くのがよいです。UIの構造が固まるというのは、どういうタイミングかというと、画面遷移が決定し、UIの各要素に意味が割り振られ、各要素にidを割り振れる状態になったときです。

基本的には、Seleniumのテストを書くタイミングは、ユースケース単位でバックエンドの機能が完成し、UIの要素についても固まったタイミングでテストを書くのがよいということになります。

結合テストの一部としての役割が強くなります。基本的には、Seleniumの結合テストは最小限にして、バックエンドのService側のLogicの単体テストを充実させるべきです。

テストの実行時間も長いため、何度も繰り返し実行できるわけではないため、Seleniumでの部分の結合テストに力をいれるというのは、あまりおすすめはできません。特に異常系のシナリオのテストをこれで充実させるのは、あまりおすすめはできません。

ただ、ユースケース単位でシナリオが一通りカバーできるSeleniumベースの結合テストを用意するのは、デグレードを防ぐという点においては有益です。

Seleniumのアクセプタンステストを実行するタイミング

それぞれテストの粒度が違うので、テストを実行すべきタイミングも違ってきます。

Cross Browser Testing

こちらは頻度は若干高めで実行したほうがよいです。デグレードする範囲が大きくなると、後で対応させるのは割に面倒です。影響範囲が小さいうちにテストをしたほうが楽になります。

この部分についても、JavaScriptが中心のアプリケーションであれば、全体のTest Suiteの実行は、SeleniumRCで定期的に実行させて、結果を朝みるという運用でも十分なケースもあるとは思います。

ユースケースシナリオのテスト
  • ユースケースのシナリオの全体のテストは、CIによるテストタイミング(日に2回程度)で十分です
  • ユースケースシナリオ単体のテストは、SeleniumIDEをベースにコミット時に影響のあるシナリオを実行するのでよいと思います。この時にSeleniumRCを使うのはテスト時間もかかり若干大げさな解だと言えます。
  • 主な目的は一部機能がデグレードしていないかを確認することになります

Seleniumのテストケースを書くときの注意点

  • テスト対象のアプリケーションのHTMLにidを割り振ること
    • テスト対象の要素には必ずidを割り振ったほうがよいです。ブラウザ毎にDOMの形が異なるため、テスト対象の要素がXPathに依存すると、cross browser testingができなくなります
  • 要素のロードタイミングに注意すること
    • wait系コマンドを上手く使わないとテストがタイミングに依存したテストケースになってしまうからです。Ajax系のアプリケーションでは注意をする必要があります

まとめ

  • Cross Browser用の結合テストにはSeleniumは最適
  • ユースケースシナリオ単位のテストは1セットは用意するのはよい。ただ、あまり時間をかけるべきところではなく、基本は単体テストを充実させるべき。

# SeleniumIDEでさくさくテストの発展系のエントリも暇をみつけて書きたいですね。HTMLのTestCaseをSeleniumRCで扱うのもよいのですが、あれはあまりテストケースの保守性が高いとはいえないので

2008-07-03

JavaScript: The Good Parts

|  JavaScript: The Good Parts - dann's blog を含むブックマーク はてなブックマーク -  JavaScript: The Good Parts - dann's blog  JavaScript: The Good Parts - dann's blog のブックマークコメント

お、Douglas Crockfordさんが本出してたのか。170pと薄いし、さくっと読んどこうかな。

JavaScript: The Good Parts

http://www.amazon.com/o/ASIN/0596517742/

John ResigのPro JavaScript Techniquesもなかなか良い本だったし、この1,2年は割とJavaScriptの本はあたりが多いかも。

http://www.amazon.com/Pro-JavaScript-Techniques-John-Resig/dp/1590597273/

とおりすがりとおりすがり2008/07/04 09:48モダンなとか言ってる時点で終わってる言語。

yappoyappo2008/07/04 12:16じゃぁモランボンで

danndann2008/07/05 00:51どんな言語でもモダンな書き方やライブラリというのはあると思いますよ。

na3na32008/07/05 09:22仕事だとモダンな書き方を許してもらえなかったりして悔しいです。

ponpon2008/07/05 13:16良く分からないけど、「モダン」ってPerl5.8.8で許されるようになった書き方とかっすか?

JohannJohann2008/07/05 16:36すごく為になる情報です。とおりすがりの茶々とか気にする必要無いですね。
ありがとうございました。

サルサル2008/07/05 23:00perlの問題点をまざまざと見せ付けてくれたという点ではすごくためになる情報だと思う。

perl48perl482010/08/27 19:42なるほど、Plaggerを学ぶと早いしモダンなんですね。ありがとうございます。