20年もののレガシーJavaプロダクトに自動テストを組み込んできた話（再）

2026年3月度関ジャバでの発表資料です。
https://kanjava.connpass.com/event/387904/

X
https://x.com/gengenmusic0719
lit.link
https://lit.link/gengen0719

Transcript

1. 20年もののレガシーJava プロダクトに⾃動テストを 組み込んできた話（再） 2026.03.31
2. げんげん @gengenmusic0719 奈良県に住むテストと設計が好きなアプリエンジニア お仕事 20年ものの基幹業務システムの保守開発チームの マネージャー → 昨年7⽉からマネージャーをやめて 新プロダクトの開発中 好きな技術トピック Java、AWS、設計、テスト、CICD、Serverless https://lit.link/gengen0719
3. 保守してきたプロダクトの紹介 とあるERPパッケージソフト → SaaS 保守期間20年越え Javaソースコード 約380万⾏ 開発組織の⼈員は 約50名（当時） Java 1.4時代のコードが残っている 当初からWebアプリとして作られているので、JSPの実装が残っていたり、 ⾊んなフレームワークの実装が地層のように積み重なっている。 このプロダクトに⾃動テストの仕組みを整備してきた経験と、新しいプロダ クトを作る際に⾃動テストを整備している経験をもとに話します。
4. 想定するオーディエンスとメッセージ - 長く運用しているアプリケーションに - これから自動テストを組み込みたい方 - 組み込もうとしてうまくいかなかった方 - 他社事例が知りたい方
5. 認識を合わせるために 初めに⼀般論の話をします
6. ソフトウェアの検証を ⾃動化する重要性
7. ソフトウェアと検証 ソフトウェアはユーザーに価値を届けるためのもの 価値を届けるためには まず意図通りに動作する必要がある その確認のために検証を⾏う
8. ソフトウェアと検証 価値を届け続けるために ソフトウェアには変更が加えられ続ける - 運⽤をしてみたら不具合が⾒つかった - 運⽤をしてみたら機能追加が必要になった - 依存するソフトウェアの変化の影響を受けて修正が必要になった - 時代の変化で価値が変わり修正が必要になった 変更が加わると検証は再度実施する必要がある
9. 検証における絶対的な原則 どちらが簡単ですか？ - 1⾏の変更を検証したら失敗しました、問題を修正してください - 1万⾏の変更を検証したら失敗しました、問題を修正してください 検証を⾏う単位を⼩さくする⽅がほぼ確実に修正が楽
10. ソフトウェアの検証を⾃動化する重要性 検証に⼈間の⼿が必要になると費⽤と時間がかかる 費⽤と時間がかかると 検証を⾏う頻度が下がったりやらなくなったりする 気づけばたくさんの修正が⼊っていて どこで問題が起きているのかわからなくなる 検証の頻度を落とすことは負のループを⽣む
11. テストサイズの話
12. ⾃動テストの繰り返し実⾏を実現するために - 準備を含めて⾃動化されていること - 冪等性を保っていること - 実⾏時間が許容できること - コストが許容できること などが重要。 これらを保って運⽤するには ⼩さいサイズのテストを多くすることが重要。
13. テストサイジング 引⽤：https://saeedgatson.com/the-software-testing-ice-cream-cone/
14. テストサイジング t-wadaさん & Google Ver 引用: 開発生産性の観点から考える自動テスト（ 2024/06版） https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202406-findy-dev-prod-con-edition?slide=40 Small 単⼀プロセス Medium 単⼀マシン Large 制限なし
15. いくつか加えて考慮すべき点 引用: 開発生産性の観点から考える自動テスト（ 2024/06版） https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202406-findy-dev-prod-con-edition?slide=40 minimum テストだけではなく検証まで広げると、 「ビルドの検証」や「静的解析」が Smallより⼩さい検証としてあり それらの運⽤も重要。 テストデータの利⽤範囲 たとえ単⼀マシンで動いていても、そのテス トで必要なデータの準備や後⽚付けがそのテ スト内でやれていないものはLarge（なぜな ら管理が⼤変だから）
16. 開発者テストと 品質を保証するためのテスト
17. 開発者テスト（TDDなどで積み上げていくテスト） 着実な⾃信を積み上げ⾼速に内部品質の⾼い アプリケーションを作るためのテスト - 振る舞いを定義できる箇所に書くことが⼤事 - 今扱っている振る舞いに集中 - ⾃分たちのためのもの - 開発者にとって呼吸
18. 品質保証のためのテスト アプリケーションが仕様や要件を満たし、 外部品質に問題がないことを確認するためのテスト - 品質保証ができる箇所に書くことが⼤事 - 全体を⾒渡してバランスも⾒る - 外に向けたもの - ⼀回⽴ち⽌まって考える
19. 品質保証のためのテストを⾃動化する難しさ 品質保証のためのテストは プロセス品質に関わり顧客への説明責任が⽣じる ⼀つ⼀つ説明できるテストを設計する必要がある 素朴に開発していくだけではできない - 分岐網羅以上のケースが必要なことも多い - 結合テストが必要なケースも多い
20. しかしスタートは開発者テストの⾃動化から - 不具合を発⾒できることももちろんある - 設計が良くなる - まずはテストを書く習慣付けから 今回のお話も まずは開発者テストを ⾃動テストにしていってみた話 （後半少し品質保証テストも含む）
21. ここから実体験の話
22. Small size Testの整備 （JVM単体のJUnit Test）
23. やった（やってもらった）こと テストの知⾒がある開発者の⽅が⼊ってきてくれて 整備をしてくれた。 私⾃⾝はここで⾃動テストの素晴らしさを知り、 たくさんJUnit Testを書くようになり、 その後仕組みの整備にも関わっていくようになった。
24. やった（やってもらった）こと - ⽇次でテストを全件実⾏する仕組みの整備 - pre mergeで変更の⼊ったクラスのテスティングペ アのテストを実⾏する仕組みの整備 - 同時にLinter, Formatterの実⾏も整備 （これらはIDEでも実⾏） - テスト駆動開発の啓蒙 （動画視聴、社内講演、ワークショップなど）
25. ⾃動テストの整備で ⼀番⼤事なこと
26. 20年以上の運⽤の中で誰もJUnit Testを書かな かったのか？ 否。 今までもJUnit Testの実装はあった。この整備が⾏われる際にも存在していた。 しかしほぼすべてが有効活⽤されておらず、Failするテストも⼤量にあった。 なぜそんな状況になってしまっていたのか？
27. 20年以上の運⽤の中で誰もJUnit Testを書かな かったのか？ 否。 今までもJUnit Testの実装はあった。この整備が⾏われる際にも存在していた。 しかしほぼすべてが有効活⽤されておらず、Failするテストも⼤量にあった。 なぜそんな状況になってしまっていたのか？ CIで実⾏されていないから CIで実⾏されないテストは腐る。間違いなく絶対に腐る。 何よりも先に準備することは 「最低毎⽇テストがCIで実⾏される仕組み」
28. JUnit TestをCIで⽇次実⾏する Small sizeのTestをCI上で実⾏することは全く難しくありません。 JavaでGradleを利⽤している場合であれば標準の test タスクを実⾏すれば良いです。 GitHub Actionsで毎⽇夜 9:30に テストを実⾏するのであればこんな感じです。 ⾮公開の内製ライブラリに依存する場合は 認証や通信経路確保などが必要になりますが、 それもそこまで難しい話ではありません。 しかしテストは書いているけど CIで実⾏する仕組みはないというプロダクトは 意外と多い
29. JUnit TestをCIで⽇次実⾏する もう⼀つ重要なのが実⾏後の通知（特に失敗時） 誰も失敗したことを知らないのは 実⾏されていないのと同じ せっかくUnit TestがあるのにCIで実⾏されていない、 実⾏結果が通知されていない、 のであれば⼤変勿体無いことなので、 すぐに毎⽇実⾏して結果の通知を⾏うようにしましょう。
30. JUnit TestをPre mergeで実⾏する より早く検証の失敗を検知できるように Small SizeのテストはPre mergeにも組み込んだ⽅が良いと思います Pre mergeとはマージされる前、という意味で、 Pull RequestやMerge Requestが作成された際にテストを実⾏し、 失敗した場合はmainブランチにマージされるのを防ぐことができます。 これによって他の開発者に影響する前に検証を⾏うことができます。 また修正者が間違いなく⾃分の修正によって失敗したことを把握できる という点も利点です。
31. Pre mergeでの実⾏時に注意すること ただし実⾏速度に関しては注意が必要です。 Pre mergeでの検証が完了するまで、マージを⾏うことができないため、 実⾏時間が⻑くなるとそれだけ待ち時間が増えることになります。 我々のプロダクトではコードセットがかなり⼤きいため、 Pre mergeでのテストは変更が⼊ったクラスのテスティングペアの実⾏に留め、 並⾏してデイリーで全件のテストを運⽤するという運⽤になりました。
32. 啓蒙活動 - テスト駆動開発の動画視聴会 TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング https://www.youtube.com/watch?v=Q-FJ3XmFlT8 - JUnit の基礎知識の勉強会 - レガシーコードにUnit Testを書くためのテクニックの勉強会 レガシーコード改善ガイドの内容を実際のプロダクトコードに適⽤ - 外部講師の⽅を招いた全社向けの講演 開発組織全体の盛り上がりの醸成と経営層への単体テストの重要性の訴求
33. Medium size Test （データベースに接続するJUnit Test）
34. やったこと - ⽇次でテストを全件実⾏する仕組みを整備 - pre mergeで変更の⼊ったクラスのテスティングペア のテストを実⾏する仕組みを整備 - 開発者が開発環境でテストを実⾏できる仕組みを整備 ほぼSmall Size Testと同じですが、 これがなかなかに⼤変
35. やったこと 実現するために以下が必要だった - データベースにアクセスするテストとしないテストの実⾏を分離 - テストクラス内でDataSource、Connectionを取得する仕組みを整備 - 開発者やCIで利⽤するデータベースのDocker Imageを整備 - テスト時のデータベースのデータの扱いのルールを整備 データベースを扱うことで⾊々な準備が必要になり、仕組みも⼤がかりに。 CIでのテスト実⾏時には全てのテストが同じデータベースを使うため、データ管理 の戦略も必要。 プロダクトの固有の事情によって異なる部分が多いものだと思いますが、 できるだけ根拠を含みつつ話しますので、⼀事例として聞いていただければと思い ます。
36. データベースアクセス層のテストの必要性 データベースアクセス層はフレームワークを使った最⼩限のものにして、 そこにはテストを書かないと⾔う考え⽅もあると思います。 確かにデータベースアクセス層に過剰なロジックを実装することは良くないと思いますが、 例えばデータの絞り込みをデータベースアクセス層で⾏うのは⾃然な実装です。 そしてそこには機能に関わるロジックがあるため、それを検証することは必要だと思います。
37. データベースアクセス層のテストの必要性 レガシーコードでまれによく出会う、責務の絞り込みやレイヤー分けが⾏われていない神クラスに 外側から包むテストを書いて保護し、その後リファクタリングを⾏うという場合にも利⽤できます。 安全にリファクタリング
38. 仕組みの実装 - データベースに接続するテストコードはmain, test とは別のフォルダに置くようにする - 専⽤のアノテーション @DatabaseAccessTest を作成 データベースにアクセスしたいテストにはこれをつけるようにする。 - gradle に databaseAccessTest というタスクを作成する - CIや開発者の端末で動かせるデータベースのDocker imageを準備（後述） - テスト⽤のConfigurationでlocalhostのデータベースへの接続を取得する仕組みを整備 （Spring未対応のコードが多いのでConnectionやDataSourceを取得するUtilityも⽤意）
39. 仕組みの実装 これで開発者の端末のIDEでは - @Test がついたテストはいつでも実⾏できる - @DatabaseAccessTest がついたテストはテスト⽤のデータベースを起動したら実⾏できる CI上では - gradle test で @Test がついたテストが実⾏できる - gradle databaseAccessTest で @DatabaseAccessTest がついたテストが実⾏できる （CI上にデータベースを起動する必要がある） という状態になりました。 開発者ローカルで実⾏する際の使⽤感を変えず、かつ データベースに接続するかどうかで明確にCIでの実⾏を分離できるように、 このような実装にしました。
40. テスト⽤データベースのデータ データベースに接続するテストで重要なのがテスト⽤データベースのデータ。 テスト前のデータベースのデータはパラメーターなので データベースにアクセスする処理の結果に影響します。 テストの冪等性を担保するため、毎回同じデータ状態である必要があり、 かつテストケースとの関連が分かるようにする必要があります。
41. テスト⽤データベースのデータ テストに利⽤するデータベースは「出荷データベース」としました。 ※おそらく社内⽤語 - テーブル定義などのスキーマ情報 - 開発者が出荷した初期データ（設定や共通機構が動くためのメタデータが多い） これらが⼊っておりユーザーデータがない状態のこと。 これをDocker Imageとして利⽤し、毎回作り直すことで同じデータ状態になるようにして そこにテストクラスのsetUpでそのテストに必要なデータを投⼊し、テストを実⾏します。 この２つを合わせてテストの前提データとする
42. テスト⽤データベースのデータ この運⽤にした理由 - すでに管理している出荷データベースのDockerイメージがあった - 新しくテスト⽤のデータベースイメージを管理していくのは⼤変 - バージョンアップのお世話をする必要がある 管理するデータベースのイメージは極⼒減らしたいので出荷データベースを流⽤した。 - テストの前提データはテストケースとの関連がわかるようにしたい テストクラスのsetUpでデータを投⼊すれば強い関連性を持たせられる。
43. テスト後のデータの後⽚付け テスト⽤のデータベースは⼀連のテスト実⾏が終わるまで使いまわされる仕組み。 他のテストに影響が出ないよう、 テスト実⾏後に「出荷データベースの状態」に戻すのが望ましい。 戻さない場合 どんどん前のテスト⽤のデータが溜まっていってしまう
44. テスト後のデータの後⽚付け（理想） Spring JDBCを利⽤してDataSourceをインジェクションしているクラスでは @Transactional を付与すると、実⾏前に @Sql やsetUpで投⼊したデータも含め、 テスト実⾏中の変更をロールバックしてくれます。 Spring JDBCを使っており、 プロダクトコードでトランザクション制御を書いていない層にテストを書く場合はこれ が楽ちん。 （新しいプロダクトはRead Onlyだったのでこうしました）
45. テスト後のデータの後⽚付け（現実） 20年もののレガシープロダクトの現実 - java.sql.Connection を直接利⽤している箇所が⼤多数 - トランザクション管理の⽅法や単位も統⼀されておらず、commit する箇所もまちまち 共通の仕組みでロールバックをコントロールすることが難しかった。
46. テスト後のデータの後⽚付け（現実） しかし仕組み化できていない状態でテストコードが増えていくと、 他のテストが残したデータ（や消したデータ）によって失敗するテストが出始めた。 他のテストの残留データ INSERT INTO USER (userId, userName) VALUES (gengen0719, じぇんじぇん); 一意制約違反
47. テスト後のデータの後⽚付け（現実） 仕組みでコントロールすることが難しかったためルールを作った - ユーザーの操作で起きえない変更はしない ⇒テーブルのDROPや初期状態で⼊っているレコードの削除はダメ。 - ユーザーの操作で起きえる変更は吸収できるように実装する ⇒Userテーブルのデータはユーザー操作で追加されうるので、消してからINSERTする ルール⾃体は定着し、 ⽇次でテストが実⾏されるため問題が起きてもすぐに修正されている。
48. テスト後のデータの後⽚付け（現実） しかしルールにするにしても - テストで変更したデータは必ずもとに戻すこと もしくは - テストで変更したデータはできるだけもとに戻すこと。もとに戻してい ないことにより他のテストが失敗した場合は修正すること というような内容の⽅が今思えば良かったかもしれない。
49. 啓蒙活動 - 外部講師の⽅を招いたプロダクト全体でのワークショップ データベースに接続するJUnit Testを取り上げてもらい、 実際のプロダクトコードを対象としたテストを実装するワークショップが実施されまし た。（私以外の⽅が実施してくれました） プロダクト全体の盛り上がりの醸成が⾏われ、全員にこの仕組みが浸透しました。 ほとんどの⼈がJUnit Testを当たり前に実装するようになりました。 - 新たにジョインした⽅向けのワークショップを定期的に開催 ワークショップ参加者の⽅がトレーナーを引き継いでいく形で定期開催を続けてくれて います。
50. Large size Test （⾃動E2E Test）
51. ⾃動E2E Testとは ユーザーの操作からレスポンスまでのEnd to End の ソフトウェアの動作を検証する⾃動テスト。 Webアプリにおいては ユーザーのブラウザ操作をエミュレートして⼊⼒として、 画⾯への反映を出⼒として検証する。 アプリケーションが完全に動作している必要があり、 忠実性は⾼いがコストも⾼い⾃動テスト。
52. ⾃動E2E Testの必要性 これまで Small, Medium のテストを整備してきたが これらだけでは最終的な結合テストとしては不⼗分なため 品質保証としてのテストをカバーしきることができない - モジュール間の結合箇所の担保の説明が難しい - クラウドサービス等の動作に依る部分が検証できない 打鍵⼯数の削減やアジリティの向上に繋げるには、 E2Eの⾃動テストが必要であると考えています （範囲は狭く保ちつつ）
53. 実装のポイント - ここでも⽇次以上で実⾏が⾏えることは最優先 - とにかくデータの準備 - 忠実性の⾼いテストなのでデータも忠実性を⾼く保つ - 対象プロダクトは別プロダクトのデータをベースに動く プロダクトの制約もあってとても⼤変 これから先もメンテナンスコストを払い続ける必要がある
54. やったこと - ⽇次でE2E Testを⾃動実⾏する仕組みを整備 そのために以下を⾏いました。 - データ投⼊専⽤の環境を作成 （打鍵評価環境相当のもの） - アプリケーション全体が動作するコピーした環境を⽴ち 上げる仕組みを作成 - コピーして⽴ち上げたアプリケーションにE2E Testを実 施する仕組みを作成
55. E2Eテスト⾃動化の効能 - 外側から包むテストを作ることができるのでリファクタ リングをする前に作っておくと安⼼ - クラス単位の挙動ではなく、アプリケーションそのもの の挙動の正しい動作を積み重ねていくことができる 運⽤していると共通コンポーネント修正の影響による挙動 不備をよく検出しています。
56. 運⽤していくために E2Eテストは品質保証のテストとして外部に説明をしやすい しかし乱⽤するとメンテナンスコストがどんどん増えていく サイズが⼩さいテストで品質が保証できていることを説明するの は難しいが、やっていく必要がある
57. 巨⼤なレガシーコードと対峙する際に ⾃動テストが与えてくれたもの
58. ポエム 私が巨⼤なレガシーコードと向き合う時に 最も苦しいと感じていたことは どこまでいっても終わらないという感覚でした。 不具合を⼀つ直して、次に別の機能の不具合を直して、 また別の機能の不具合を直して、 そうして最初の不具合があった機能に戻ってきた時に、 前回読んだコードの内容を忘れて、またやり直しになる。 そんなことを繰り返して 何も前に進んでいないように感じることがありました。
59. ポエム ⾃動テストは巨⼤な既存コードを読み解いた記録を 残すことができる地図になってくれます。 少しずつ実装を⾏い、確実に実⾏を繰り返すことで、 ⼀歩ずつ前に進んでいる実感を与えてくれます。 そして今は巨⼤な製品でも、 品質保証のためのテストを積み上げていき、 打鍵⼯数の削減やアジリティを取り戻すことができると 信じさせてくれています。
60. おわり