フロントエンドではE2Eテストだけでも書くようにした

起こったこと

現在運用中のフロントエンドだけで動いているWebアプリケーションについて、テストコードが全く書かれていない状態だったので、ユニットテストなどをいろいろすっ飛ばしてE2Eテストだけでも書くようにした。

やったこと

とにかく既存機能のE2Eテストを書く

今の動いている通常の機能だけでもE2Eテストを書いた。これから出来る新機能やバグ修正パッチが完成する前に作り終えないと、これから発生するエンバグの時期がわからなくなる。E2Eを作成中に出来上がった新機能についてはいったん考えない。とにかく既存機能にテストを書く。

既知のバグを再現する手順をテストを書く

かつて発生したバグが出た操作をE2Eに記載する。既知のバグで修正済みのはずなので、実行すればパスするはず。だよね？

ユーザーの動きに近い再現方法を書くのが良いのか、それとも機械的に最短で再現できる方法を書くのが良いか、いつも迷う。

新機能や新バグを見つけたときは都度E2Eに追加していく

上の２つが出来たら開発チームに横連携して、レビュー、マージする。チームには新機能を開発する、あるいはバグが発生したときは都度E2Eを書くようお願いする。

あきらめたこと

PlayWrightでいろんなブラウザで起動すること

PlayWrightには３つぐらいブラウザが同時に実行されるけど重いからChromeだけでも動かすようにした。これ本当にCIで実行できるのだろうか。

E2Eだけでテストを網羅すること

受け入れテストを完全にE2Eで自動化に出来そうだと思ったけど、やっぱり人によるの検証は別途必要そう。モンキーテストのような、そういうテストは人間がやらないとだめだ。特に文章がおかしいとか、文字がはみ出ているといったテストは人間がやらないと見つからなさそう。書いていること以外のことはできないのがE2Eなんだと思った。

頑張りすぎること

もう少し頑張ったらきれいで汎用性の高いものがかけそうだったものがあるのだが、まずは終わらせることを目標とした。そうじゃないと延々とテストコードを書き続けることになりそう。終わりがないのが終わり。

テストコードがあると安心

つぎはぎ感があるがテストコードがかけた。これがあると新機能を作るときにもエンバグの怖さがだいぶ減る。書いてよかった。いま、テストコードが足りていないアプリについてはテストコードを書くようにしよう。