なぜ、テストデータを投入するのか？
テストデータが整備されている開発案件に一度だけ会ったことがあります。入ったばかりの私でも、全画面を初日に動かすことができて、とても快適でした。
もしテストデータがなければ、画面遷移を確認するためには、テストデータを作るところから始めなければいけません。テーブル数が多く、外部キーがびっちり張り巡らされていたら、テストデータを作るだけで1日が終わってしまうでしょう。
テストデータを配布することで、開発時の画面間の疎通確認もやりやすく、結合テスト前からバグを潰すことができます。何よりテストデータ作成工数がなくなるのは大きいでしょう。
テストデータが整備されていないとしても、いずれにせよマスタ系のデータは配る必要がありますよね。ついでに簡単なテストデータを配布して、開発メンバの開発体験を向上させましょう。
テストデータを投入する方法
テストデータを投入する方法はたくさんあります。それは、INSERT文をどのように実行するか？と言う話になります。
１．INSERT文を書いたSQLを配る。
原始的ですが、これでも全然OKだと思います。テストデータが用意されているだけでありがたいですので。
メリットはSQLをソースコードとは別管理することで、ソースコードへの影響が一切ないことです。。
デメリットといえば、手動でファイルの中身をコピー＆SQLクライアントにペースト＆実行するのがややめんどくさいだけでしょうか。（A5-SQLなんかはSQLファイルを開けるし、ファイルから実行できるので、特に問題ないですね。）
２．flywayMigrateでINSERT文を実行する。
flywayでDBマイグレーションを行っている場合、flywayの仕組みに乗っかることができます。
INSERT文を書いた、V1__insert_data.sqlのようなSQLファイルを作り、flywayMigrateを実行するだけです。
メリットとしては、flywayの仕組みが使えるので、新たな設定や技術習得が不要です。
デメリットとしては、本番環境ではテストデータは不要なので、データ削除用SQLファイルを別途用意するか、手で削除する必要があるということでしょうか。（そこまで工数がかからないですが）
３．APIのロジックの中で入れる
JPAを使っている場合はこの方はやりやすいです。テストデータ投入用のAPIを用意して、ブラウザから叩いてもらうようにします。
デメリットはごみAPIが発生してしまうことでしょう。また、INSERT文直接書くに比べて、Entityをnewしたり値をセットするのはコード行数が以外とかさみます。
メリットはロジックで自由にデータを作成できることです。ループ回数を指定したり、ランダムな名前や数値も作りやすいでしょう。