はじめまして！Graat（グロース・アーキテクチャ＆チームス）の名も無きフロントエンジニアです。
この記事はグロースエクスパートナーズ アドベントカレンダー13日目の記事です。
この記事の対象読者は、次のような開発をしている人です。
- Webアプリケーションを開発している人
- ExcelでWeb画面のスクリーンショットを取るのが仕事になりかけてる人
- 修正するたびに想定外のレイアウトの崩れが発生して、心に闇を抱え始めてる人
はじめに
プログラミングってとても楽しいですけれど、仕事で長く続けて積み重なっていくコードは怖いですよね。
とくにWebの画面構築は、シンプルな場合思った通りにレイアウトできるけれど、小さく部品化したり、他と組み合わせて要素がネストした構造になってしまったりすると、長くメンテしていくうちに予期しない見た目の崩れが発生することが多々あるので困ります。
フロントエンド開発における愚痴とかあれこれ
そんな現在のWebアプリケーションは、意外と簡単にEnd To Endテストの自動化の導入ができるようになっていて、ビジネスクリティカルな機能やマネタイズとして外せない機能においては自動化・省力化やSemantic Monitoringなどの導入は、私の身の回りで良くみます。
また、ビジネスクリティカルな機能やマネタイズとして外せない機能以外のテストまで細かく書くと、アプリケーションが肥大化するにつれコストが見合わなくなり、楽をするためにテスト自動化してるはずなのに、テストのために苦しむという負の連鎖を生み出す原因になることもしばしばでした。
かといって機能は増えますし、画面の修正は発生するのが現実です。
修正したあとに些細なレイアウト崩れの確認を怠って、QAチームがいるからいいやって確認を押し付けるのは全体的に見て無駄なコストになるし、チーム全体の空気もわるくなっちゃいますよね。
また、そんなことをしてるとQAチームの稼働があがってビジネスクリティカルな部分のチェックが漏れてしまうのは本当避けたいお話です。
そして、QAチームも人間なので、いくら多重チェックしていたとしても前回の画面を細かく覚えてないから、些細なレイアウト崩れの見落としは当然でてきます。
そうなるとチーム間で冷戦がはじまってプロジェクト全体の空気が険悪に・・・
転生しました
1週目の私はそういう経験をしていたようなので、運よく転生した2週目の私はそうならないよう知識チートにより開発チーム内でレイアウト崩れを早期検知して、平和なスロー開発ライフを目指します！
スロー開発ライフの実現には、次のような物を準備する必要がありました。
- 画面のしょうもないレイアウトの崩れでも、サクッと見つけれる。
- わかりやすく、よみやすく、シンプルなテストコードをサクッと書ける。
- 自分の触っている部品が他の画面で影響ないかがサクッとわかる。
つまり冷凍した袋ドーナッツのごとく安心してサクサク開発したいのです！
そのために私たちがたどり着いた解決方法は、Cypressを利用したビジュアルリグレッションテストの導入でした。
ビジュアルリグレッションテストとは？
一言で言うと、前回と現在の画面を比べ、変化があった場合に検知する仕組みです。
Cypressのビジュアルリグレッションテストはコードベースのe2eと違って、振る舞いやページの遷移、セマンティクスやwai-ariaなどのテストは出来ませんが、可視化可能なものをテストする場合は導入が非常に簡単であり運用のコストも安い優れたソリューションです。
どれくらい簡単なのか興味がある方は、以下のリポジトリのREADMEに書かれている手順をやってみてください。
10分程度で終わるので、サクッと体験できると思います。
サンプルコード
このようなビジュアルリグレッションテストは、次のような構成の時に特に力を発揮します。
- デザインシステムでUIを構築しているシステム
- コンポーネント指向のシステム
- CI/CDが準備されている開発
もちろん、上記以外の構成でも利用できますし、メンテナンスが多々あるのであれば、フラットなHTMLページでも十分対費用効果が高いソリューションです。
また、マイクロフロントエンド構成かつデザインシステムを利用している場合はStorybookなどと合わせた導入であれば、テストの時間や内容を効率化することも可能です。
Cypressを利用したビジュアルリグレッションテストの注意点
しかしながら、実際に運用していくと、次のような点を留意する必要が出てきます。
- MacやWindowsなどの異なるOSを利用した開発者が複数いる場合でも、皆同じ画像が生成されるようにする必要がある
- どのタイミングでビジュアルリグレッションテストを実行するのか計画する
- １つのテストケースでは１回の画像比較に留めておく（共通レイアウトの変更のせいでテストが将棋倒しにならないようにする）
- Cypressのsnapshotイベントではresizeが発生（画面が一時的に縮小される）ので、resizeに対する対策をする必要がある
- 画面の修正をしたら、どうやって比較用の画像を更新するのかの手順を考えておく
- 時間で new Date()など、ローカル自国を画面に表示しているケースは、実行するごとに画像にずれが出るためcy.clock()などの時間を固定にする必要がある
- アニメーションがある場合はキャプチャタイミングのズレにより差分が発生するため、なるべくアニメーションはOFFにできるソリューションをアプリに組み込んでおく。
- 比較用の画像を保存する必要があるため、何処に保存するのかと容量の問題をあらかじめ考慮しておく
細かく画像キャプチャを取ると時間がかかるため、差分テストやクラウドビルドなどを利用する
まとめ
ビジュアルリグレッションテストそのものは導入して5年以上たちますが、立ち上げ当初に行っていたseleniumベースで自作していた時代と比べると、Cypressを利用したビジュアルリグレッションテストは圧倒的にローコストで導入できメンテナンスしやすいため、これは十分他のプロジェクトでも横展開する価値がある物だと実感しています。
下手をすると、適切に導入できればユニットテストよりも維持コストが安く、解決できる不安は自動化ソリューションの中でも随一であるため、本当に何の不安もなくサクッと実装・テストをできるようになります。
さらに、維持コストがやすいためテストケースも結構幅広いユースケースを書けたおかげで開発チーム内でのケアレスミスの発見数が増えQAチームへの負荷が下がり、関係性もすごく良いものになりました。
所感
レイアウト崩れの確認は気力をとっても使うので共通部分の修正は正直嫌でしたが、ビジュアルリグレッションテストを利用することで平和な開発が行えるようになりました。
いまは修正によるレイアウト崩れを気にしていた気持ちもどこかに去って、他チームとの交流も楽しいものとなっています。
みなさんも是非、ビジュアルリグレッションテストを導入して平和なスロー開発ライフをおくってください。