Selenimを改造する
前回の続き
Seleniumをプロジェクトに導入するにあたって懸念するところがいくつかあった。
１．画面に変更が入るとテストコードを書きなおす必要がある
まぁこれはある程度は仕方がないかなと思ってる。
ただ、画面に変更が入るということは
-
- 画面設計書を修正する
- テスト仕様書を修正する
- JSPなどを修正する
- ロジックを修正する
- テストコードを修正する
っつぅ感じで手間がかかりまくる。
設計書やJSPからテストコードが自動生成できたらかっこいいなぁ。
２．テスト対象画面にたどり着くのが大変
例えば共通で使う画面や必ず通る画面とかの処理をテストメソッド毎にバカみたいに書くのか？ってこと。
その共通の画面に変更が入ったら全テストメソッドをバカみたいに書きなおすのか？ってこと。
こんなバカみたいなことは絶対にやりたくない。
この辺をうまいことできるフレームワークを考える必要がありそう
４．Selenium自体に多少バグ(仕様なのかも)がある
これは回避できる方法があるんだけど、知らない人は普通にバグにはまってしまうだろう。
だからこれを回避するような共通処理をかます必要があるかな？と考えた。
さらなる要望
テスト毎にデータを変えられたらいいねっつぅこと。
これはdbunitを使ってできる。大した問題ではないな。
で？どうする？
まず、２．を解決するために、各画面をテストから切り離そうかと思う。
-
- ページクラス・・・1画面をあらわすクラス。画面項目を保持し、操作を提供する。
- テストクラス・・・ページクラスを生成し、操作する。
こうすることで、画面に変更が入ってもテストクラスで修正する必要はなくなったりする。
ただ、項目の追加、削除などは修正する必要がある。でもコンパイルエラーになるので修正すべき箇所が一目瞭然になるっつうメリットがある。
さて、２．が解決したところで思いついた。
画面設計書からページクラスが、テスト仕様書からテストクラスが自動生成できそうだな。
というわけで１．、３．も解決？
まぁ画面設計書は多少詳しく書かなきゃいけなくなるのと、フォーマットを決める必要があるけどね。
４．に関しては、ここまでくるとちょっとしたテストフレームワークになってきたのでいっそのことSeleniumを隠してしまおうかな？と。そうすればSeleniumのバグとかは全部見せなくて済むしね。
テストコードができるまで
-
- 画面設計書を書く
- テスト仕様書を書く
- 設計書からテストコードを生成
