はじめに
私は法令・規格調査を効率化するため、生成AIを活用しながら個人開発を続けています。
AIのおかげで、以前は難しかった機能も実装できるようになりました。
しかし、開発を重ねるうちに、一つの修正が別の機能に影響を与える場面に何度も直面しました。
「今、正常に動いているコードが、次の修正後も正しく動くと、どう確認すればよいのだろう？」
この疑問が、Regression Test（回帰テスト）を学ぶきっかけになりました。
今回は、実際の開発経験と、回帰テストを取り入れるまでの過程を紹介します。
1. 修正したら、別の機能がおかしくなった
私が開発しているツールの一つに、JavaScriptで作成した計算・表示ツールがあります。
機能を一つずつ追加し、ブラウザで結果を確認していましたが、機能が増えるにつれて、変数や関数のつながりが複雑になっていきました。
実際に、ある計算結果がすべて「Neutral」と表示されたり、ReferenceError（存在しない変数などを参照したときのエラー）が発生したりしました。
AIに修正を相談すると、すぐに解決策を提案してくれます。しかし、その修正が別の機能に影響しないかまでは、提案されたコードだけでは判断できません。
AIによってコードを書く速度は上がりましたが、正しく動くことを確認する作業も同じくらい重要だと感じました。
2. 回帰テストという考え方を知った
その後、既存のJavaScriptの計算処理をPHPへ移行する準備を始めました。
そのときに気づいたのが、**「変更前の結果を残しておかなければ、変更後の結果が正しいか比較できない」**という問題です。
そこで取り入れたのが、Regression Test（回帰テスト）です。
回帰テストとは、プログラムを修正した際に、それまで動いていた機能が引き続き動くかを確認するテストです。
例えば、次のようなイメージです。
| 確認項目 | 変更前 | 変更後 |
|---|---|---|
| 計算A | 10 | 10 |
| 計算B | 20 | 20 |
| 計算C | 30 | 25 |
この場合、計算Cに差があるため、修正による影響なのか、意図した変更なのかを調べます。
変更前の出力を保存しておけば、こうした違いを見つけやすくなります。
3. 実際に取り組んだこと
JavaScriptからPHPへの移行準備として、既存の計算結果を保存する仕組みを整えました。
取り組んだ内容は、大きく4つです。
- 基準を決める： Gitで変更前のコードのバージョンを特定する。
- 入力を固定する： 同じ条件で計算できるようにする。
- 結果を保存する： JavaScriptの出力をJSON形式で記録する。
- 結果を比較する： 新しい実装の結果と照合し、違いを調べる。
このとき学んだ技術用語が、Baseline（比較の基準）とFixture（テスト用に用意したデータ）です。
ただし、一つ重要な注意点があります。
変更前後の結果が一致しても、その計算が絶対に正しいとは限りません。
元のプログラムに不具合があれば、同じ不具合が残っている可能性もあるためです。
つまり、「以前と同じ動作をしているか」と「計算そのものが正しいか」は、別々に検証する必要があります。
4. この経験から学んだこと
以前は、エラーを修正して画面が正常に表示されれば、次の作業に進むことが多かったと思います。
しかし、今回の経験から、コードを変更する前に既存の動作を把握し、変更後に比較できる状態を作ることの大切さを学びました。
個人開発では、最初から大規模なテスト環境を用意するのは難しいかもしれません。
それでも、一つの入力条件と計算結果を保存するところから始められます。
また、AIは便利な開発パートナーですが、何を変更し、何を維持するかを判断するのは、開発する側の役割だと感じています。
まとめ
今回の経験で得た学びは、次の3つです。
- 変更前の動作を記録しておく。
- AIの修正提案も、既存機能への影響を確認する。
- 以前と同じ動作をすることと、計算が正しいことを区別する。
まだすべての機能を自動テストできているわけではありませんが、少しずつ検証できる範囲を広げています。
これからもAIを活用しながら、単に「動くコード」を作るだけでなく、**「安心して変更できるコード」**を目指していきたいと思います。