Visual Regression Test(回帰テスト)を実施することになったので、自分用にメモしておく
Node.jsでWebアプリを開発している想定
Visual Regression Testとは
ビューに崩れがないか確認するテスト。 開発を進めていくと、意図しないビューの変更が加わる事があるので、それを防ぐことを目的とする。
以下は、自チーム用の方針。
いつおこなうか
毎日定時に実行
正のビューについて
ビューに崩れがないか確認する場合、比較対象が必要になる。これを正のビューと呼ぶこととする。 テストの流れは以下のようになる。 1.正のビューを用意する。 2.テスト対象のビューと正のビューを比較し差分を検出する。
何を正のビューとするか
本来ならばデザイン時に正のビューを作って用意することが望ましいが、現状ないので、最新バージョンのものを正のビューとする。
この方法では、もし最新バージョンのビューがすでに仕様と異なっていた場合、Visual Regressinoテストでその間違いに気づくことができない。デザインに変更がある場合は正のビューのデータを更新する必要がある。
正のビューは画像として用意する
HTML＆CSSのテキストファイルとして用意する方法もあるらしいが、テスト対象のページがJavaScriptを使用しているページなので今回は除外。静的ページならその方法でもよさそう。動的要素をどのようにあつかうか
同じページを表示しているのにバナーやカルーセルがあると、それらを差分と誤検知してしまう問題がある。
これらに対する対策は、
1.visibilityをhiddenにする。
2.バナーやカルーセルにダミーのデータを用意する。
などが考えられる。今回は、テスト用のライブラリなどに従い、visibilityをhiddenにする方向で行く。
検討過程
案1.定期実行
メリット 開発スピードに影響を与えない。
デメリット PRが複数取り込まれていたとき、デグレの原因がわからなくなる。 (実際に開発していると、ビューに影響があるPRかどうかはすぐにわかると思う)
動作イメージ 定期的にビューのデータをS3に保存する。 保存したテスト対象のビューと正のビューを比較する。
案2.PRオープン時
メリット デグレの原因がPRに含まれていることがわかる。
デメリット スクショを撮るのに時間がかかるため、PRマージのスピードが遅くなる。
動作イメージ PRオープン時に全てのビューをartifactsに保存する。 保存したビューと正のビューを比較し、その結果でCIをsuccess/failさせる。
以上を考えた上で、 ・デザインの変更は日常的に多くない ・スクリーンショットを撮るのでテストにある程度時間がかかる(開発のスピード感が失われる) ことを懸念して定時に実行することにした。
