Pitaliumを使った実際のワークフローについて
Pitaliumはスクリーンショットを利用して画面の差分比較ができるのがPitaliumの最大の特徴です。そのためにはまず基準となるスクリーンショットが必要になり、それをテスト実行モードで切り替えることで実現しています。今回は実際に差分比較を行うためのワークフローを見ていきましょう。
なお、利用しているのはTODO管理になります。
実行モードについて
画面比較を行うにあたって基準となる画面をキャプチャするのですが、Pitaliumには幾つかの実行モードがあります。それぞれ次のようになっています。
モード | 内容 |
---|---|
TAKE_SCREENSHOT | スクリーンショットの取得のみ(Assertionは無視) |
SET_EXPECTED | 比較基準値となる画面を作成するモード(デフォルト) |
RUN_TEST | 基準画面との比較を行うモード |
このモードは以下のファイルに記載するか、JUnitの実行時パラメータに含めることで変更できます。
src/main/resources/environmentConfig.json
{
"execMode": "RUN_TEST"
}
JUnit VM実行パラメータに含める場合
-Dcom.htmlhifive.pitalium.execMode=RUN_TEST
モードの詳しい仕様はライブラリ仕様 – hifiveでも確認できます。
現在の状態を保存してみる
それではテストを行うための比較基準となる画面を取得してみましょう。先に説明したとおり、モードをSET_EXPECTED
として実行するだけです。
なお、デフォルトで指定がない限りモードはSET_EXPECTED
となります。この場合、当然ですが画面比較は行われませんので注意して下さい。
public class PitaliumTodoTest extends PtlTestBase {
@Test
public void test1() throws Exception {
// TODOサイトのトップページを開きます
driver.get("http://www.htmlhifive.com/ja/tutorial/todo/");
// 比較対象を使用して検証を実行します。
assertionView.assertView("ToDoTOP");
}
}
上記をテスト実行すると、デフォルト設定では次のディレクトリに各画像や基準値のデータが設定されます。
実行日付のディレクトリ以下、テストクラス名とその画像が保存されます。以下は、そのディレクトリ例です。
results
├── 2015_11_10_13_43_41
│ └── PitaliumTodoTest
│ ├── result.json
│ ├── test1_ToDoTOP_MAC_chrome.json
│ ├── test1_ToDoTOP_MAC_chrome.png
│ └── test1_ToDoTOP_MAC_chrome_TAG_NAME_body_[0].png
└── currentExpectedIds.json
この中で、currentExpectedIds.json
に、基準値となる情報が入ります。
{
"PitaliumTodoTest" : {
"test1" : "2015_11_10_13_43_41"
}
}
上記の場合テストケースのtest1
は、result/2015_11_10_13_43_41
にある基準画像を利用するという意味になります。
比較してみよう
それでは、実際に比較してみましょう。テストケースから画面TODO項目を追加する処理を入れて比較してみます。実行モードは、RUN_TEST
として下さい。
public class PitaliumTodoTest extends PtlTestBase {
@Test
public void test1() throws Exception {
// TODOサイトのトップページを開きます
driver.get("http://www.htmlhifive.com/ja/tutorial/todo/");
// 新しくTODO内容を追加します。
driver.findElementById("txtTodo").sendKeys("新しくTODO追加");
driver.findElementById("btnRegist").click();
// 比較対象を使用して検証を実行します。
assertionView.assertView("ToDoTOP");
}
}
上記でJUnitを実行すると、項目が新しく追加されて基準値となる画面と比較して変更が出ていますのでテストはエラーとなります。

※ 画面はIntelliJ IDEAのものです。
以上が、Pitaliumの画面比較機能の利用方法です。
部分的なDOMに変更があった場合
Pitaliumはもう一つ画面比較の特徴があり、DOMレベルで画面比較が可能です。Pitalium 1.0.1で加えられたBuilderパターンを使用し、addNewTargetメソッドでDOM要素を設定します。DOM要素は複数指定可能です。
@Test
public void test2() throws Exception {
// TODOサイトのトップページを開きます
driver.get("http://www.htmlhifive.com/ja/tutorial/todo/");
// 比較対象をDOMレベルで指定します。
ScreenshotArgument arg = ScreenshotArgument.builder("ToDo-LastChild")
// 撮影対象を指定
.addNewTarget(SelectorType.ID, "list")
.addNewTarget(SelectorType.CSS_SELECTOR, "#list tbody tr:last-child")
.build();
// 比較対象を使用して検証を実行します。
assertionView.assertView(arg);
}
また、部分的に比較を行わないという操作なども可能です。次のように、addExcludeメソッドで指定します。
@Test
public void test3() throws Exception {
// TODOサイトのトップページを開きます
driver.get("http://www.htmlhifive.com/ja/tutorial/todo/");
ScreenshotArgument arg = ScreenshotArgument.builder("ToDo-LastChild")
// 比較対象をDOMレベルで指定します。
.addNewTarget(SelectorType.ID, "list")
// DOMレベルで除外指定します。ここでは、最後のTODO項目を除外します。
.addExclude(SelectorType.CSS_SELECTOR, "#list tbody tr:last-child")
.build();
// 比較対象を使用して検証を実行します。
assertionView.assertView(arg);
}
テストケース・エラー時のワークフロー
実際のプロジェクトが進めば、当然エラーになるケースが出てくるでしょう。この場合、まずはエラーとなったケースを見極めることから始めます。大きく分けて次の2通りとなるでしょう。
テストケースが問題の場合
- 画面のレイアウト変更があった
- 文言の修正が入った
- 動的なコードが挿入された
テストケースが問題の場合は、もう一度基準画面を取り直すことでOKでしょう。ただし動的なコードが挿入された場合は比較から除外するなどのテストコード修正が必要になります。
コードが問題の場合
- 間違えてCSSを弄った
- 間違えてレイアウトを変更してしまった
こちらはテストケースに影響がないので対象のクラスや画面テンプレートを正しく変更し、再度テストを行えば良いでしょう。
また、Pitaliumの画面比較チェックは当然ですが内部的なコードの解析は行われません。その辺りは、Selenium側のテストで行えばよいでしょう。
最後に
Pitaliumを利用した画面比較のワークフローを見ていきましたが、いかがでしたでしょうか。簡単に設定が可能ですし、ワークフローさえ手順化されていればテストで迷うことはないと思います。
ただしPitaliumの画面比較を導入する場合は、その導入時期を見極める必要があるでしょう。頻繁に画面が更新される初期の開発において画面比較チェックまで含めてしまうとテストケースで頻繁にエラーが起こり、その都度テストが止まってしまう可能性が大きいです。導入は時期を見て、画面レイアウトが固まった段階で行うべきでしょう。
Pitaliumにご興味のある方はチュートリアル(Pitalium:hifiveリグレッションテストライブラリ) – hifiveも参考にして下さい。
過去のPitaliumの投稿はこちら
コメントは受け付けていません。