0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

E2Eテストをフロントとバックが分かれた構成で行う場合のデータテスト運用

Posted at

背景

現代だと、フロントエンドとバックエンド(APIサーバ、BackendForFrontend)がのリポジトリが分かれるケースが多く、
個々のリポジトリでのケースはテストできるけれども、
フロントエンドからバックエンドにつなぐテストはスタブ化してしまうケースが多いです。
(RubyonRailsでerbファイルとしてhtmlを表示している時代はあまり気にしなくてよかった)

そこで両方をテストするE2Eテストツールを調べてみると、
E2Eとは名ばかりの単なるブラウザ操作ツールが並ぶことが多いです。

そこで、実際複数リポジトリをまたいだテストするときに、どのような構成なら運用できるのか、
自分自身のN=1のケースと、DeepResearchでの調査結果を載せておきます。
(E2Eでデータテストができてしまったがゆえに、E2Eが多くなりすぎる問題はアイスクリームコーン問題としてまた別問題)

自分の経験

E2Eテスト環境を用意

自動テストを行う専用の環境を用意しました

状況

  • スマホアプリを使って行うE2Eテストを行いたかった
  • 利用テストツールはMagicPod
  • もちろんバックエンドは別リポジトリ(RubyonRails)

やり方・特徴

  • E2E用の環境を用意
  • データ作成・更新スクリプトを用意
    • バックエンド(Rails)側にデータ作成・更新スクリプトを用意
    • 開発環境だけで使えるURLを叩くとそのスクリプトが実行されるようにする
      • そのスクリプトで作るデータは1テストケース用のユーザなりデータを毎回発行して、他のテストに鑑賞しないようにする
  • テストが1周終わったら、DBをクリーンアップ

メリット

  • 何よりも自動化ができたこと
  • スタブせずに環境が出来上がるから、フロントからバックはもちろん、バックエンドから他のマイクロサービスへの通信も行える

デメリット

  • 同じDBを使っているから並列でテストできない(考えれば回避可能な気もする)
    • 1回テストが回っているとき(A)に、もう一周同時に行おうとすると(B)、Bの実行中にAのクリーンアップが行われてしまうかもしれない
    • E2Eはこまめに回せるように、少ないシナリオテストだけ実施するようにして、この問題には対処していました

DeepResearchでしらべた結果

実際今回の記事で力入れているのはここだったりします。
私自身、自分の経験での1パターンしかなくて、どうやればもっとよくできるだろうと思ってDeepResearchでしらべたらいい案が出てきたので備忘録として載せておきます

E2Eを行うソースコードでDBを直操作

こちらの記事では、データ初期化するSQLを直に実行しています。
私のやり方はある種バックエンド依存であり、そのフロントエンドがバックエンドを介して、DBのデータを当てにしていると考えると、DBにつなげてしまうのも、直接的で面白いなと思いました

ヌーラボ社のケース

こちらのケースではE2Eは手動と自動を組み合わせて、
テストデータ作成自体をdumpファイルで自動化すると言ってました。
実際手動でしかできないケースも多いので納得です。全自動ではなくても、自動化できることを自動化するということで。

(おそらく)テストごとに環境生成

テストパフォーマンスの話をしているんですが、
どうもテストごとにインフラごと環境を生成して、終わったら捨てるという運用を前提としていて、
その上でどう効率化するかするかという話をしていました。

k8sを使っているがゆえに、AWSなどを使わずにスクラップアンドビルドができる環境がゆえに思いつく方法だと思いますが、やれるならこれもありかもと思いました

ここからインスピレーションを受けて、フロントのリポジトリとバックエンドのリポジトリで、それぞれに閉じるテストを書いているなら、
E2Eを行うリポジトリを立てて(またはフロントのリポジトリ内)、そこのテストでフロントとバックのDockerイメージを立てるテストをしてもいいのかなとも思いました

(余談)E2Eテストを増やしすぎるな

E2Eテストを増やしすぎないための記事もヒットしてなるほどなって思いました。
ただ単にアイスクリームコーンがだめっていうものもあれば、「じゃあどうするか」っていう記事もあって面白かったです

終わりに

E2Eっていう言葉が当たり前に浸透しているけれども、そのナレッジっていうのは、ゴロゴロころがっているわけではないっていうのはちょっと意外な発見でした。
話しやすいE2Eフレームワークの使用方法ばかりは転がってるんですが、各開発組織が頭に汗かいて考えていることは転がっていないんだなっていう。

改めてDeepResearch強いなって思いました。
昔は、袋小路くらいいろんな事情に陥った状況で、それを調べようとすると、高いネットサーフィン力と1日がかりの時間を要しましたが、それを任せられるの強いなって思いました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?