SeleniumのGoog/Badから考えるアクセプタンステスト
Seleniumは使いこなすと非常に強力なテストツールですが、向き不向きもあり、テスト用途によって、どのようなテストをどのようなタイミングで実行すべきかを変えた方がよくあります。そこで、SeleniumのGood/Bad、Seleniumのテストの用途、Seleniumのテストを書くべきタイミング、注意点についてまとめました。
今、何のテストを書いているのかを意識し、それに応じてテスト方法とテスト計画を変える事は、アプリケーションをテストする上でとても役に立つのではないかと思います。
では、それぞれ見ていきましょう。
SeleniumのGood/Bad
SeleniumのGoogな点
- Cross browser testingが簡単
- browserの指定だけすれば同じTest Suiteで複数のブラウザをテストする事ができます。これはSeleniumを使う事の最大のメリットです。
- テストケース作成のコストが低い
- SeleniumIDEがあるために、テスト生成が極めて簡単でテスト作成のとてもコストが小さくなっています
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で定期的に実行させて、結果を朝みるという運用でも十分なケースもあるとは思います。
