background
Ranorexは自動化のツールとしてここ最近主流になりつつある。
自動化のプロジェクトが大きくなるにつれて、Ranorexのrecording moduleやrepository、test suite等一定のルール(coding rule）をまとめないと大変であることが見えてきた。
ただ、これをまとめたサイトがあんまりなかったので、個人的にruleをまとめてみた。
それが視聴者に適合するかはわかりませんが、参考になればと思います
尚、最低限のルールしか定義しない。拘束しすぎるとコーディングに負担になるため。
前提
- 自動化のテスト対象はWebで、E2E test
- Ranorexの言語はC#を使用
basic rule
- 変数で未bindのものはなくす（compileでwarningが出るため、発見可能）（設定忘れを防ぐ）
- データソースはUTF8を使う（環境によって文字依存が起きる）
- Compile時、Warningを極力ゼロにする（bind されてない等）
Variable rule
まず、変数として大きく２種類ある。
また、local変数も使われ方によって２種類ある。
変数がどの種類であるかを明確化すると、取り扱いに苦労しない
| 変数の種類 | 命名規則 (ex) | 意味 |
|---|---|---|
| 定数 | XXXXX_XXXXXX (大文字) | Test suite全体で共有する定数 global parameter※1で定義する |
| global 変数 | global_xxxxx | Test suite全体で共有する変数 global parameter※1で定義する |
| local 変数 Data Binding用 |
xxxxx | Data Drivenでデータをbindingする変数。※2 基本的に、変数名とData sourceの変数名は一致させる |
| local 変数 Recording module内用 |
local_xxxxx | Recording module内でのみ利用する変数。 Data sourceとbindしないため、compile時にwarningになる。 回避するためには、parameterでdefault値をbindする |
※1 global parameter 定義
※2 bind 変数と parameter 定義
Recording module rule
File name
ファイルの探しやすさ、何の機能テストであるかをわかるように定義する。
例えば、以下のように構成したとする（楽天競馬の機能テストを例とする）
smart holderの上位階層の名前を継承し、最後に具体的に何の処理をするmoduleであるかを記述する
${Level1}_${Level2}_ .. ${action}
recording module のサイズ
1 recording moduleを細分化すると、ファイル数が肥大化する。
1 recording moduleに多く定義すると、ファイルの中でどこになんの処理が定義されているかわからなくなる。
そのため、このバランスが必要。
お勧めは、まずは一連のシナリオを１つのrecording moduleでscriptingする。
その後、他のシナリオで共通して使う部分を抜き出し、分割する。
最初から１画面１スクリプトといった定義の基にcodingすると、ファイル数が肥大化し大変なことになる。
action 記述
基本的に、captureした順に自動的に登録される。
処理の可視性をあげるために、例えば以下のタイミングでコメント挿入を行う
- 画面遷移
- １ページが長い処理の場合、処理をグルーピングする
Coding rule (C#)
Ranorexはcapture & replayの自動化ツールである。
ただ、それだけでは効率性がよくない、実現できない等が起きる。
そのとき、C#でUser codeでprogrammingする必要がある。
ただし、Ranorexの利用者を考えて、User codeのレベルを先に明確にしておくべきである。
- User codeが複雑になると、メンテナンスコストが上がる
- 非プログラマ（マニュアルQAエンジニア）が利用するとき、理解できなくなる
非プログラマと共存することを想定したときの、User Codeの利用ルールの例として、以下のに挙げる
1 関数 1 action
1つのユーザー関数には１つのユーザー行動を定義する。
1つの関数で複数のユーザー処理を定義しない。
関数名 命名ルール
この関数で、ユーザーの何のアクションをするのかを分かるように命名する。
例
${条件}_${ユーザーアクション} // 何かの条件でもって、ユーザーアクションを実施する関数
Regex_GetValue_XXXXX // 正規表現を用いて値を変数に入れる関数
デフォルト処理
このrecording moduleを呼び出された時の初期化は Init classにて定義する
A HotDocument 形式コメント
User 関数の処理概要を記述する
//
// 機能 : XXXXX
//
// 機能説明 : XXXXX
//
※Ranorexは戻り値をハンドリングできないため、(基本的にvoid）省略
ex)
User codeをバリバリ書くつもりはないが、C#のcoding ruleがMicrosoftで記載されていたので
参考として挙げておく ↓
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
Repository rule
Repositoryは画面の要素を指す。
要素はXpathで定義される。
Basic Repository rule
- domain 単位でdom を作成する（図で"ログイン"）
- 一定のパーツ単位でSimple Folderを作成する (図で"楽天会員ログインForm"）
- 画面要素は一意に特定できるxpath要素で定義する（図で"パスワード"） （後述）
- Repository名は、できる限り画面の要素名と合致するものとする
- 適切なXpath (Xpathは長すぎず、短すぎずとする)（後述）
- index番号はあまり使用しない（後述）
一意のXpath
Xpathの取り方により、要素が複数Hitする場合がある。
そのため、Spyで要素が一意に特定できるかを確認する。（ただし、複数でも問題ない場合は除く）
適切なXpath
階層が多いXpathの例
この場合、デザイン変更が入った場合、要素が認識できなくなる可能性が高い
階層が少ないXpathの例
この場合、要素を特定するのに時間がかかり、自動化の処理が遅くなる可能性がある
index番号はあまり使用しない
repositoryを特定するとき、index番号で指定することができる
その場合、レイアウトが多少変わると（indexが変わる）、失敗する。
そのため、極力index番号を使わず、class名などで特定するようにする
index番号指定
class名指定に改修例
