はじめに
明けましておめでとうございます、ログラスでエンジニアをしております南部です。
さて唐突ですが、ログラスでは大まかに以下のようなテストの作成と実施がされています。
- JUnitで作成された単体テスト・結合テスト
- 実際にプロダクトを触ってのE2Eテスト
後者のE2Eテストは、ユーザー目線でのテストができると言う点で非常に価値のあるテストです。
一方で、実施にあたっては非常にコストがかかります。
特に直近では、そのコストは開発作業を圧迫しかねないほど大きくなりつつあると認識しています。
そこで、E2Eテスト自動化を各開発チームが行える基盤を整え始めました。
まだまだ道半ばですが、単体テストや結合テストと同様に組織に定着することを目指しつつ、まずはスモールスタートしましたのでその取り組みを共有させていただきます。
また、今後の展望についても記述できればと思います。
これから開発チームにおいてE2Eテスト自動化を始めたい方の参考になりましたら幸いです。
また、似たような取り組みを行なっている先駆者からのフィードバックやアドバイスもウェルカムです。
ログラスでのE2Eテスト自動化導入の背景
状況
ログラスには複数の開発チームがありますが、各チームそれぞれが複雑な機能の開発に注力しています。
かくいう私の所属するチームも、直近で複雑かつ前提となるテスト環境の構築に手間がかかる開発をしております。
そのため、直近開発している機能を高品質にリリースするには、テスト工数を即座に減らす必要がありました。
また、機能開発に使うリソースをできるだけ保持するためには、テストを開発する工数についても小さくする必要がある状況でした。
課題
E2Eテストにおいて直面した最大の課題は、お客様の環境に相当するテスト環境の構築コストの削減でした。
会計ドメインの複雑さやお客様ごとの独自のデータ要件、さらには不可逆な作業を行うことも考慮すると、テスト環境は毎回作成しなければならない場合もありました。
これは多大なコストで、場合によっては、テストの工数に圧迫されて開発の工数がどんどん取れなくなってしまう状況になっていると感じていました。
解決策
解決策としてはE2Eテストを自動化することなのですが、その進め方においてスモールスタートすることを意識しました。
スモールスタートで意識したことは以下の2点です。
- 全てのユースケースを網羅するのではなく、後の拡張性を持たせた状態で一部のユースケースに焦点を当ててテストを実装すること
- まずはローカル環境でのテストに絞り、CIなどでの実行は後回しにすること
これにより、自動化の導入を思い立ってから1営業日で基盤を作るところまでを行えました。
導入を思い立った時のコメント(2023/11/17(金))
基盤を作って共有した時のコメント(2023/11/20(月))
次のセクションからは、スモールスタートにあたって実際に行ったことなど具体的な話を記述します。
Playwrightを用いたE2Eテストの実装
選定の理由
ログラスでのE2Eテスト自動化にPlaywrightを選択しました。その理由は以下です。
- カスタマイズ性の高さ
昨今、Autifyやmablといった便利なノーコードツールが出てきています。
しかし、今回私は開発チームがテストを拡充していくような想定をしていましたので、ノーコードツールの便利さよりも、カスタマイズ性の高いコーディングでテストを作成するツールを求めていました。 - 社内知見の有無
ログラスでは、ログイン監視用にPlaywrightを既に使用していました。これが、導入においてヒントになり、導入コストを下げてくれる状態でした。 - コスト面の利点
Playwrightは無償で利用できるため、金銭的コストを考える必要がありませんでした。
我々のようなコスト感を意識するべきフェーズのスタートアップ企業にとって、これは非常に大きな要素です。
叩きとなるテストの選定と実装検証
代表として実装するテストの策定
Loglassでは、お客様のデータをExcelでアップロードしてもらうことが主要機能の利用の出発点です。Excelのアップロード機能がなければ、E2Eテスト自動化はできません。
逆に、Excelのアップロードさえできてしまえば、他の機能はLoglassの中の操作で使用できます。
また、ログイン情報など秘匿性の高いものはリポジトリの管理外にしておきたいという要件もありました。
以上から、最初の実装としては、ログイン→Excelアップロードを絡めたユースケースを検証することとしました。
具体的には、「お客様のデータを擬似的に模したテストデータを取り込み、その値を見て正しい数字が入っているか確認するテスト」を実装しました。
Excelアップロード機能の実装
問題視していたファイルアップロードですが、公式サイトに実装方法の記載がありました。
LoglassではモーダルからExcelをアップロードします。
これに合わせ、実際には以下のようなコードで実装しました。
// 実績ファイルをアップロード
await page
.getByText('ファイルをドラッグ＆ドロップまたはファイルを選択')
.locator('input')
.setInputFiles(`./resource/${filePath}`);
await page.getByRole('contentinfo').getByRole('button', { name: 'アップロード' }).click();
ログイン情報をリポジトリ管理外とする実装
Playwrightでは、dotenvなどを用いて.env ファイルにある情報をテストに用いることができます。
これは公式にも記載があります。
これを利用して、.envファイルを.gitignoreに登録してログイン情報はリポジトリ管理外とするようにしました。
環境変数は playwright.config.ts内で以下のように読み込むようにしています。
(Playwrightをセットアップした段階からconfig()部分はコメントアウトされた形で記載されていました。)
/**
* Read environment variables from file.
* https://github.com/motdotla/dotenv
*/
config();
if (!process.env.LOGIN_USERNAME || !process.env.LOGIN_PASSWORD) {
throw Error('.envファイルにLOGIN_USERNAMEとLOGIN_PASSWORDを設定してください');
}
開発チームに定着させていくために
既に文化として浸透している単体テストや結合テストのように、他の開発チームにも広げていく活動をしました。
開発組織全体へのSlackでの共有のほかに、現在までに以下のようなことを行なっています。
- 拡張性を持たせた汎用関数の作成
- ドキュメントの充実
- モブプロの実施
拡張性を持たせた汎用関数の作成
Loglassを操作する上で、サイドバーの要素選択などは頻繁に行われる操作です。
こういった操作は汎用的に作成して問題ないため、拡張性を持たせた状態で必要な分だけ作成しました。
また、汎用関数を置いておくディレクトリを作成し、そこからimportする形にしています。
参考までに、ディレクトリ構成は以下のようにしています。
.
├── README.md
├── helper // 汎用関数を置いておくディレクトリ
│ └── sidebar.ts
├── package-lock.json
├── package.json
├── playwright.config.ts
├── resource // ExcelファイルなどInputに使うファイルを置いておくディレクトリ
│ └── excel.xlsx
└── tests // 実行されるテストファイルを置いておくディレクトリ
└── sample.spec.ts
テストを作成する開発者は基本的に、helperディレクトリの中のファイルから適切な操作を探し、テストしたい流れを実装していくだけとなります。
そのため、helperディレクトリ内が充実していくほどテストが書きやすくなっていきます。
ドキュメントの充実
READMEには、環境構築の方法を説明したNotionページへのリンクを記載しています。
いつでも開発者が環境構築できるようにドキュメントを整備しています。
環境構築記事の一部
また、LoglassのバックエンドはKotlinで実装されているため、多くのエンジニアは親和性の高いIntelliJ IDEAをエディターとして用いています。
本来、Playwrightはマイクロソフト製のツールなので、同じくマイクロソフト製のVisual Studio Codeと相性が良く、開発体験もVisual Studio Codeを用いた方が良いです。
しかし、E2Eを書くときだけエディターを変えるとなると実装ハードルが上がってしまうと考えました。(少なくとも私はエディターの切り替え作業にストレスを感じてしまいます)
そこで、IntelliJ IDEAでの開発もできるだけ快適に行えるようにREADMEに記載しています。
IntelliJ IDEAの公式にも方法の記載があり、Test Automationのプラグインを有効にすることでPlaywrightの実装と実行においてさまざまな便利な機能を使うことができます。
モブプロの実施
私の所属するチームにおいての話にはなりますが、私の作成した基盤を元に実際に開発中の機能に対するE2Eテストを自動化しました。
この際に、最初は私の画面を見てモブプロを行う形で共有を行い、その後すぐに手分けをして各画面のテスト作業を自動化する実装を行いました。
この間、共有を含めて2時間ほどで完了しており、コストをそれほどかけずテストが作成できることを体感してもらいました。
今後の展望
今後、さらにE2E自動化テストを活用していくために、下記を考えています。
- CIによるテストの確実な実行
- 各チームへの(必要とあれば)E2Eテスト自動化の実装方法や文化の展開
- どのような場合にE2Eテストを作成するのか、E2Eテストのログラスにおける立ち位置の整理
最初の2つは他のエンジニアの協力も得つつ現在進行中です。
今回実装した人の手によるローカル実行ではなく、機械的にテスト実行できるようにすることで、プロダクトの品質維持に貢献できると考えています。
また、E2Eテスト自動化という選択肢を浸透させていくことで、開発生産性や品質の向上につながると考えています。
最後の1つが一番難易度が高く、かつ一番重要なことと考えています。
私個人としては、どんな場合でも自動E2Eを実装することが正だとは思っていません。
必要なときに必要な分だけ実装するのが良いと考えています。実装しなくて良いならそれが一番コストを下げられるからです。
E2Eテスト作成の判断基準として、
- どういった場合に自動E2Eを実装した方がよいのか
- 1つのユースケースに対しどれだけのパターンを用意したらいいのか
などをQAメンバーと相談しながら、開発組織として一緒に考えていければと思っています。
まとめ
E2Eテストの自動化をスモールスタートした際に行ったことを記載しました。
今後の展望で記載したように、まだまだやることはたくさんあります。
しかし、一刻も早くテストのコストを削減したい現状がある中でE2Eテスト自動化の選択肢がエンジニアの頭の中にインデックスされている状況を作りだすことが爆速でできたことはとても価値があったと感じています。
今後の展望に書いたことを進めていき、複雑な機能も、品質面で安心してリリースできる開発ライフを送れることを目指して活動していきたいと思っています。
本記事がE2Eテスト自動化をしようか検討している方の一助となれば幸いです。
Discussion