E2Eテスト自動化でAutifyやseleniumを採用しなかった理由
以前の記事の補足
この記事では手動で行っていたE2EテストをAPIを叩いて疑似る形で自動化したが、そこに至るまでに検討したツールと、導入しなかった理由を補足する。
検討・試作したテストツール
1. Autify
2. selenium
3. seleniumIDE
1. Autifyの検討
自分がジョインした時にはすでにAdvancedプランが導入されていた。
導入経緯としては 「そこまで忙しくなさそうな非エンジニアチームにテスト実行を任せられないか？」 という案の元、ノーコードで使用できるAutifyが導入されていた（らしい）。しかしそのチームでは上手く運用できず、であればと 「開発チームでシナリオを作って運用してみよう」 となったものの、コアな動作を数シナリオ回すだけで、新たにシナリオ作成する人はいなかった。
「まぁせっかくだし触ってみようか」 と真っ先に着手してみたが、すぐに 「これはキツイな……」 となった。
原因は主に以下の３つ
・実行が遅い
・シナリオ管理の難しさ
・カスタマイズ性の悪さ
実行が遅い
Autifyの動作は良くて「人間が最速で動かすよりちょっと早い」程度。スマホアプリのように画面要素が少なければこの理論値に近づけるが、要素が多いWebアプリだとその分操作速度は遅くなり、実行時間が延びる場合がある。プロダクトのフロントの造りによるので一概には言えないが、例えば「<td>タグの一番上のリンクをクリック」みたいな動作は安定して30秒以上かかていたり……とりあえず並列実行とかそういうので何とかなるレベルの話ではなかった。
Autifyのシナリオ管理の難しさについて
Autifyは画面遷移の成否(前回実施との差分)など、人間が一目見てわかるレベルの差分はしっかり検出してくれるが、細かなデータの値は都度しっかりと読み取る動作や、値を判定する等、シナリオに記載する必要がある。なので今回のようなデータチェックしたい且つパターンが多い場合は不向き。
Autifyのカスタマイズ性について
カスタマイズ性が薄いとは、ツールの外側でどれだけテストに関わる操作が出来るかのこと。
特にこのプロダクトだとE2Eテスト中にDBを操作する必要あった為、それをAutifyで実現しようとすると
①テストプラグインからDB操作できるAPIを追加、シナリオ中にjsコードで叩く
②テストプラグインからDB操作できる要素をGUIに追加、シナリオ中に入力
③DB操作できるテストコード内でAutifyのシナリオAPIを叩く
①②→当時シナリオで変数の持ち回りが出来なかった(今はできるかも？）ので不可。
③→API経由でAutifyシナリオ実行のできても、結果のレスポンスはないので、非同期的に結果取得のAPIを叩く必要があるし、シナリオもそれ相応に切り分けなければいけないのでものすごく設計が複雑で手間になる。管理も 『Autifyを呼ぶコード』 と 『Autifyのシナリオ』 の二種類になる為、非常にやりたくなかった。
2. seleniumの検討
Autify検討後 「どうせコード管理するならseleniumでよくないか？」 と考えて試作。チームに展開してみたが 「これを態々運用したいと思わないな」 とエンジニア目線のリアクションはイマイチ。自分も特にseleniumを使い込みたいわけではなかったので保留。
3. seleniumIDEの検討
seleniumIDEでパパっとシナリオ作って、そのコードをパパっと使えたら良いなーと思って試してはみた。
一通りやって気付く。「これ手順化してお誰もやりたくなさそう……(自分もやりたくない)」
オマケに作業用PCをMacとWindowsから任意で選ぶタイプのプロジェクトだったので、そこで何かあった時の検証とかが面倒になること間違いなし。
そもそも既存のツールでいきなりテスト自動化するのは無理筋だった
色々模索しているうちに、そもそもこのプロダクトにおいて 「期待値の数値化」 が困難であることが分かった。
前回記載の前提で記載した通り、仕様が複雑なのにドキュメントは整備されていないので、まずはそれら期待値を作ることから始めるべきなのだが、どれだけの項目数になるかも不明(最終的には2000項目程度になった)で、それら一つ一つに時間をかけて期待値を設定しても、 どこに影響のあるのかわからないロジック変更 が取り込まれてしまえば、誰も知らない期待値を一つ一つ追従しなければいけない。無理である。
ここで 「少なくとも 『テスト実施』の自動化と 『期待値との突合』の自動化は切り分けないと進まんやろな……」となる。仮にseleniumを使用するにしても操作の自動化が限界、さほど実行が早いわけでもない上に他のメンバーは明らかに 「selenium覚えるのメンドイ」 という顔をしている。
もうそれなら 「curlとかrequestsで叩いてGUI操作疑似ったほうがほうがよくないか……」 となり、これら３つのテスト自動化は廃案となった。ここまでが前記事のstep1である。
まとめ
Autify,selenium,seleniumIDEによる自動化も検討・試作したが、以下の理由で長期的なチーム運用に適さないと判断した。
- Autify：実行が遅い。エンジニア目線でシナリオ管理のモチベーションが沸かないのと、カスタマイズ性が悪い。
- selenium：そこまで早くない。seleniumを触りたがる人が周りに居ない。
- seleniumIDE：seleniumと同様＋ローカル環境差分(Win勢とMac勢がいて色々面倒)
Discussion