作っていたアプリの背景
プロジェクトのタイプ
JSP + Servletのシステムをクラウド移行し、さらにSPA+マイクロサービス化してオーケストレーションシステム上で稼働させる。
利用していた言語など
フロント：Vue.js
フロントテストツール：Vitest
バック：Spring（SpringBoot）
テストツール：Junit
何故カバレッジ100%を目指したか
理由は単純で要件定義でカバレッジ100％を謳ってしまったから。
そうしたことで、.vueであろうが.jsだろうがすべてのコードに対して、テストコードを書く必要が出てしまった。
100%を目指したときの辛かったこと
（ほとんど）意味のないテストを書く必要がある
たとえば.vueでは文字が表示されているかだけのテストを書く必要がでて、その結果壊れやすいUTコードが爆誕した。
他にも、ボタンを押下したときにrouter.push()を発火するだけの関数で、ボタンを押下したらrouter.push()が呼ばれるというだけのテストを書く（レビューする）のも地獄だった。
テストが多くなったことで問題もあった
単純に分量が多いため、見るのが疲れる。
チームから段階的にレビューが上がってくるが、最終レビューをする際に何のテストをしているのか見る余裕もなく、気が付いたら全然検証されていないテストがされている箇所が増えていた。
（これはレビュー体制や、コーディングの標準化に問題があったという話もあるが）
UATフェーズでテスト修正が回らなくなった
UATフェーズ（お客様の受入テスト）で障害が頻発したときに、UTソースの修正が追い付かなくて、結果UTソースは実行しても通らない状態になってしまった。
正直カバレッジを満たしていないので直す必要があるが、直したところで意味のあるテストにはならないからやれとは言いづらい。みんな残業してソース修正している中でMust作業以外は放り込みたくない。
またそれが原因で、パイプラインでVitestを通すことを諦めてしまった。CICDとは。
今ならどうするか
今新たにやるのであれば、自動テストですべてカバーすることは諦める。
例えば以下に絞る。
- ロジック（store/utilの.jsファイル系）はテストする
- 表示や単純な委譲（router.pushなど）はテストしない
- 画面系のテストはexpressなどで立てたスタブサーバーを利用するなどしてローカルでの打鍵確認をする。もしくは結合テストに寄せる
- カバレッジは結果であるから目標にしない
最後に
ざっとの肌感覚ではあるが、大体そうしていくとカバレッジも全体としては50%を切るくらいに落ち着くんじゃないかと思う。
自動テストのやりすぎ、望みすぎは毒。
単体テストで取り除くべき障害を考えてテストは設計しよう。