保守フェーズから始めるテスト自動化
こんにちは！ハンズラボの古迫です。
テスト自動化やってますか？テスト自動化と言っても、ユニットテスト、機能テスト、APIテスト、UIテストなど様々なテストの自動化がありますよね。今回は自動化したE2Eテストを作った話をお届けします。
目次
なぜテスト自動化に取り組んだか
テストと言うとどういう印象を持っているでしょうか？私はめんどくさい手間がかかるという印象を持っています。しかし、ユーザーに価値を届けるためにやらなければならないことです。どうせやらなければいけないのであれば、自動化できるものは自動化したいというのが取り組むきっかけでした。
また、追加で改修を行うことによるデグレードを少しでも防ぎたいという思いもありました。デグレードを防ぐためにはリグレッションテスト(回帰テスト)が必要です。テストを自動化することで、リグレッションテストをいつでも短い時間で実行できる状態になるため、デグレードを防ぐことに役立ちそうだと考えました。
E2Eテストの自動化に取り組んだ理由
自動テストで確認したかったことは、システム上の複数の画面で操作した結果として、計算した数値が正しいかどうかです。そして、以下のような点を考慮した上で、画面を操作してテスト実施するE2Eテストを自動化しようとしました。
- 計算処理の画面改修が頻繁に発生しないので、自動化したE2Eテストが壊れにくい。
- 一般的に、自動化したE2Eテストが壊れる原因となってしまう、「画面が変更されたことによる要素の取得失敗」の可能性が低い。
- 自動操作時のスクリーンショットを保存しておきたい。
- 現在手動で行っているテストは画面操作が多い。
- 「画面操作を自動化」することで効果を感じやすそう。
実行環境
テスト対象はWebシステムです。ローカル端末でブラウザを立ち上げ、システム操作を自動化することを目指しました。
E2Eテスト実行ツール
SeleniumやPuppeteerなど様々なE2Eテスト実行ツールの中で選んだのは、CodeceptJSです。これはPlaywrightやPuppeteerなどの他E2EテストツールのWrapperのようなライブラリです。
CodeceptJSを選んだ決め手としては、他のE2Eテスト実行ツールと比較し、メソッド名が直感でわかりやすいこと、取得する要素を簡単に記述できることなど、一番コードが読みやすそうだなと思ったためです。
手前味噌ですが、CodeceptJSの使い方イメージは以下リンクも参考にしていただけると嬉しいです。https://qiita.com/5frisk_notmintia/items/bbacebabe9050cd5c8cc
PDFのDiff比較
PDFのDiff比較のためにdiff-pdfを使用しました。
基本的には画面上に出てくる値をCodeceptJSのseeXXX()やassert()で比較します。しかし、テスト対象システムの都合上、比較したい数値がPDF帳票のみに出力されるものもあります。そのため、PDFのDiff比較を行いました。
工夫した点
E2Eテストコードを書く上で工夫した点です。複雑なロジックを作り込まないこと、必要な操作だけをテストコードに書くことを意識しました。
データ駆動型テスト
テストパラメータとして「自動テストで入力する値を管理するデータ」と「assertするための結果比較用データ」をテストコードにハードコーディングせず、別ファイルで管理しました。
これにより、「計算処理をテストコードで実装しない」、「テストパラメータを追加すれば、別パターンのテストを簡単に追加できる」ことが実現できました。
PageObjectパターン
PageObjectパターンを使用してテストコードを作りました。Webページの各画面をオブジェクトとして管理することで保守性を担保するデザインパターンです。詳細についてはここでは割愛しますので、気になる方は以下のリンク等を参照ください。https://www.selenium.dev/ja/documentation/test_practices/encouraged/page_object_models/
マスタデータや利用者データは予め登録
テストを実行するために必要な前提条件について、全ての前提条件を自動化を目指しませんでした。例としては、E2Eテスト用のデータとわかるように「E2Exxxx」の様な値で予め登録しておくことで、ユーザー登録操作を自動化せず、システムで計算処理を実施する操作のみを自動化対象としました。
テスト自動化対象機能の見極め
折角テストコードを書いても、優先度/重要度が低い機能を対象にするとメンテナンスコストだけが増幅してしまいます。テストコードはリグレッションテストのコストを下げられることを踏まえて、投資対効果を考慮する必要があります。今回は重要度が高い機能である「システムの計算処理」を自動化対象としました。
実施しなかった点
全てをできれば良かったのですが、時間も限られていること、そして自動化したE2Eテストの経験がないということもあり、まずはテストが安定して動く状態を優先しました。
- 並列実行
- 厳密なPageObjectパターンの適用
- ヘッドレス化
感想
自動化したE2Eテストを実行することで、リリース前にデグレードを検知ができました。何度でも少ない時間で実行できることで、デグレードの発生可能性を低くできることが出来て良かったです。また、目視での確認が減るので確認ミスも減らせることも嬉しい点でした。うまく活用すれば、自動テストで定義している部分については、品質が担保されていることを証明することができそうです。
一方で、自動化したE2Eテストだけで全てカバーできるわけではないので、それ以外の部分のテストは別途必要です。
今後も自動化できる部分を探して自動化できるようにがんばります！
