受入テストを整理したいと思ってやってること
まだまだ途中なんですが、とりあえず今こういう方向性でツールを触ってますよ、といったあたり。この用途だったらこっち使うべきだろう、というのがあったら知りたかったり。
なお、今回はツールの切り出しをしていないのでリポジトリの納品はございません。ご了承ください。
受入テスト
今のポジション的に私が一番責任を持たなきゃいけないのはプロダクトの要求を決定することです。要求の決定といった場合、何が達成されていれば完了とみなすか、という検証事項の決定も含まれます。主に事前に予測されるシナリオベースでの検証項目となりますが、本エントリではこの検証項目のことを受入テストと呼びます。
これらは先日のエントリでも書いた通り、FeatureMapを使って内容の管理を行っているわけですが、シナリオって結構定型文を意識して書いちゃいますよね？でもって、そんなシナリオできっちりかけることって、自動化できそうなところ多いですよね？
というわけで、なるだけ自動化できるように頑張って整理してみることにしました。
やりたいことのイメージ
受入テストの組み合わせのベースとなるドキュメントと画面遷移図からUIテスト自動化フレームワークに必要なテンプレートを自動で出せればいいなあ、とそういう感じです。実際のテストを書くところについては人力でいいかな、と。ってか、そこまで定義できないし。
実際にやっていること
で、ここ数週間の成果です。
流れ
さっきの図に、使っているツールとどの辺に人力がかかってるか書き加えてみました。
もう、この辺のツール選定(テキストベースから生成する感じ)が、エンジニア上がりという感じですね。GitHubやBitBucketでPR送ってレビューできるということを前提にツールを選んでいます。
使っているツールについて
少し説明
受入テストについては、ケースの生成をPICTで管理しています。フィーチャーごとに以下のテンプレートに沿った形でPICTのモデルを作ってる感じですね。必要に応じてフィーチャーごとにケースの制約条件を細かく書いています。
目的: 操作: 状況: 結果: リカバリ内容:
過去分をseedにして以前のケースを維持しながらテストケースを出力したり、とか細かいことは他にもやっています。ただ、FeatureMapのフィーチャーと1対1で対応づけるとあまりこのモデルがあってないので要改善です。seedの管理よりはGebのSpecテンプレートを生成するようにした方がいいのかな、と思いました。
また、テストケースに今の所PICTでなければならないほど複雑なシナリオのモデルにしてないのでオーバースペックです。状況を重ね合わせたケース漏れは防げると思ってますが。これだったら、シナリオの文章管理だけでもよかったんじゃないの？とか思ってます。テストシナリオを作る上でも要素が少なすぎて柔軟性がないですし。リリースを重ねて整理したいところです。
GebのPageクラスについては、guiflowの画面遷移図から画面の記載を抜き出して生成するようにしています。生成できるのはクラスのテンプレートのみで、 content や取り込むモジュールについてはデザイナからもらったHTMLをもとにコツコツ人力でやっています。アプリケーションの要件に応じてHTMLのタグにid要素つけていったりしないとテスト書きづらいので、このタイミングでやっているという感じです。
余談
この環境をコツコツ試している時に実行環境のJVMのバージョンをあげ忘れてて(1.8.0_11)、Groovyが古いバイトコードに対応しておらずにGebのテストがこけるなんてこともありました *1 。ちょっと前のMySQLのJDBCドライバといい、バージョン違いの罠を積極的に踏み抜いております。JVMのバージョンはちゃんとあげておきましょう。
これから
まだ、最初のリリースに向けた受入テストの整理ですし、リリース重ねることを考慮したらもっと改善したくなるポイントはあると思いますが、他にもやることあるのでこれ以上はちょっと手をかけすぎかな、と。ツールもまだ作り始めたばっかりなので、実案件でもう少し使ってプロセスから整理したいと思ってます。問題ないところはツールとして固めて、Githubにリポジトリ作ろうかと。
guiflowからGebのページクラスのテンプレート生成については、クラスの構造まで生成を自動化するのは無理なので、もうこれしかなかろうな、というところ。ここはしばらく手を入れる必要はなさそうです。
まあ、このGebのテストを自分で書くかどうか、というのはまた悩ましいところで。。。世のプロダクトマネージャの皆様方は受入テストにどこまで携わってるんでしょうかねえ？
