Jestでテーブル駆動テストを書くときに考えたこと
tokumaruy課題
今担当している自社システム（バックエンド）では単体テストはそこそこかいてはあるものの、システムを通してビジネスロジックを検知するテストコードがありません。
また、e2eテストはそれらしく書いてはあるものの、安易に追記しfatにしていくと脆いテストになってしまいがちで偽陽性を内在させることになります。
（もう少し捕捉を。うちのサービスでは他部署のAPIを叩くことになるのですが、開発環境のスペックが弱いのであまり頻繁にリクエストを飛ばすとお叱りを受けてしまいます。もう涙で枕を汚したくありません）
打ち手
そこに対して、インテグレーションテストをテーブル駆動テスト設計を採用し、実装するときに考えたとことや課題感を記していきます。
【捕捉】
・テーブル駆動テストの参考記事：https://zenn.dev/kimuson13/articles/go_table_driven_test
・インテグレーションテストとは？：ここでいうインテグレーションテストとは、外部サービスに問い合わせをするものを全てモックし、レスポンスが予期した値になることを確認するテストになります（他サービスやDBをモックしています。なので、開発環境独自のスペックからくるタイムアウトによるfailも避けています）
tokumaruyテーブル駆動テストの採用理由と課題
詳細は参考記事やネットで調べてみてください。私たちのチームは、以下の強みに目をつけて採用しました。
- テストケースの視認性→テストケースの漏れ防止
- データとロジックの分離→適切にテストケースを区切っていけば、データのモック・テストコードの工数が必要最低限にまとめられる
うちのサービスのコアドメインでは、ロジックが複数のクラスにまたがって検証しているためテストケースの列挙ですら骨が折れます。加えて、モックデータを逐一書いていくともうテストファイルの記述量が増えていき、メンテナンス性がガクッと下がってしまいます。
それらを解決してくれて、テストコードの追加・改修も用意に思えたので採用しました。
ただし、
ここで問題になってくるのは、2の適切にテストケースを区切っていけばの前提条件。
ここが今回の肝になり思考を通していくのですが、その前に軽くJestの参考記事を載せておきます。Jest触ったことある人なら呼び飛ばして大丈夫です
Jest
あまり詳細は述べませんが、軽くおさらいがてら触れておきます。
Jestのテストの書き方なんだっけ？となっている方はご覧ください。最初の記事だけ見ておけば内容（設計）は把握できると思います。
基本のキ
よくハマる モックのクリア方法について
clearMock, resetMockの違い。前テストの結果を残してしまうと、実行順変えただけで失敗するようになります。
describe,it なんかわかりにくいな...
違和感を覚えてたので調べてみたら、同じような意見の人がいました。
いい感じに言語化されているので、ご覧ください（特に技術的なところではないですが、参考になったので紹介させていただきました）