近年、生成AIが急速に成長しており、いかに生成AIを業務に活用できるかで生産性が大きく変わってきています。
AWSの生成AIアシスタントであるAmazon Qは、製品としてAmazon Q Developer、Amazon Q Businessを、AWSサービスに対する生成AIアシスタントとしてAmazon QuickSight、Amazon Connect、AWS Supply Chainを提供しており、提供機能がどんどん拡充しています。
特にAmazon Q Developerは、2024年末にAmazon Q Developerプラグインでユニットテストの自動生成機能が提供されたため、製造コストの削減に役立てられるか注目していました。
新規プロジェクトでユニットテストを導入する場合、学習・実装コストが高くなることが多く、業務アプリの実装レベルよりもテストモジュールの実装レベルの方が高いように感じます。
今回、ユニットテストの自動生成機能がどこまで実用的に利用できるか技術検証しましたので、注意点も踏まえて紹介します。
検証環境について
2025年3月時点で、Amazon Q Developerによるユニットテスト自動機能が利用できるIDE（統合開発環境）は、JetBrains IDEsとVisual Studio Codeの2種類です。
今回は、利用ユーザーが多いVisual Studio Codeを利用し、プログラム言語はJava（Spring Boot）で検証します。
Amazon Q がサポートするIDEの詳細は以下URLを参照。
https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/q-in-IDE.html
環境セットアップ
Visual Studio Code の拡張機能から、Amazon Qプラグインをインストールします。
Amazon Qの利用方法を聞かれますが、どれを選択しても問題ありません。
今回は、［Ask using chat］を選択します。
サイドメニューに表示されたAmazon Qのアイコンをクリックします。
Amazon Qへのサインイン方法として、［Use for Free］を選択して[Continue]をクリックします。
「認証サイトを開きますか？」と問われますので、［Open］をクリックすると、ブラウザにAWSの認証サイトが表示されます。
認証サイトの「AWS Builder IDの作成」画面で、認証情報となるEメールアドレスを入力して、[次へ]をクリックします。
認証サイトの「パスワードの設定」画面でパスワードを入力して、AWS Builder IDを作成します。
指定したEメールアドレス宛に送信された検証コードを入力して、［検証］をクリックします。
Visual Studio Codeで［Use for Free］を選択した状態で[Continue]をクリックし、サインインします。
「認証サイトを開きますか？」と問われますので、先ほどと同様に［Open］をクリックし、認証サイトを開きます。
Visual Studio Codeからのアクセス許可を問われますので、［アクセスを許可］をクリックします。
認証リクエストの完了画面が表示されます。
Visual Studio Codeの下側に表示されている［Amazon Q］が赤い背景色になっていなければ、セットアップは完了です。
ユニットテストモジュールの自動生成
Visual Studio Code で、ユニットテストモジュールを作成したいクラスファイルを開き、サイドメニューのAmazon Qアイコンをクリックし、プロンプト欄に「/test」と入力して［Enter］をクリックします。
今回は参照ライブラリが多くなり、モック処理が複雑になりがちであるサービスクラスファイルを対象としています。
対象モジュールのユニットテストモジュールが生成されるので、内容を確認して［Accept］をクリックします。
実際に自動生成されたユニットテストモジュールを確認すると、C2カバレッジに対応したユニットテストモジュールが生成されていました。
下の画像は、C2カバレッジとしてテストされるUploadFile メソッドを抜粋したものです。
UploadFile メソッドに対して、C2カバレッジを満たしているのが分かるテストメソッドが以下です。
If文の各条件を満たすテストメソッドが生成されていることが分かります。
ただし、自動生成されたユニットテストモジュールを実行する上で、以下の問題があることが分かりました。
＜テスト実行における問題点＞
- 軽微なコンパイルエラー
- JUnit5でMockitoライブラリを利用するためのアノテーション設定が漏れている
- ビルドファイルの依存関係（Mockitoライブラリ）が自動追加されていない
自動生成後の補完作業
前項の挙がった問題点に対して修正していきます。
① 軽微なコンパイルエラー
赤の波線（コンパイルエラー）になっている箇所を修正します。
（この場合、無効なimport文が記述されているため削除します。）
② JUnit5でMockitoライブラリを利用するためのアノテーション設定が漏れている
JUnit5でMockitoライブラリを利用するためには、@ExtendWith(MockitoExtension.class)のアノテーションが必要となるため、付与します。
（今回はサンプル的なアプリであり、テストコンフィグを使用しないため、@SpringBootTestは削除しています。）
ビルドファイルの依存関係（Mockitoライブラリ）が自動追加されていないユニットテストモジュールの自動生成時に必要となるMockitoライブラリがbuild.gradleに追加されないため、手動で追加します。
カバレッジ取得
実際にカバレッジを取得してみます。
1つのテストメソッドでエラーが発生しており、DemoServiceクラスのカバレッジ率は93.48%となっています。
実際のエラー箇所（上図の右側）を確認すると、146,147行目に、不要なモック処理（実際に到達しない処理に対してモック化する）があるため、「UnnecessaryStubbingException」が発生しています。
エラーが発生しているテストメソッドで呼び出している先のDemoServiceクラスの処理は以下となっており、45行目で処理終了となるテストケースであるにも関わらず、47行目と51行目の処理に対してモック処理を設定していることになります。Mockitoライブラリの仕組み上、不要なモック処理があると意図的に『UnnecessaryStubbingException』を発生しますので、不要なモック処理を削除する必要があります。
不要なモック処理を削除するため、コメントアウトします。
再度、カバレッジを取得してみますが、カバレッジ率は93.48%のままのため実際のソースを確認します。
例外処理をチェックするユニットテストが漏れていることが分かります。
不足している箇所に対して、手動でテストメソッドを1つ追加して再度カバレッジを取得します。
DemoServiceクラスに対するカバレッジ率が100%になったことを確認できました。
検証結果
対象ファイルに対して推論し、精度の高いユニットテストモジュールを自動生成してくれることが分かりました。
8割近くのユニットテストの工数が削減できるのではないかと考えています。
＜良い点＞
- テストフレームワークの専門知識がなくても、難しいモック処理を自分で記述しなくて済む。（重要）
- C2カバレッジが90%以上を満たすテストモジュールが自動生成できる。
＜考慮が必要な点＞
- 自動生成されたユニットテストモジュールが使用するライブラリは、自分で設定ファイルに記載する必要がある。
- C2カバレッジを100%にするためには、自動生成されたテストだけでは不十分であり、一部自前でテストメソッドを実装する必要がある。
（他のテストメソッドを流用して作成できるため、大きな問題ではない。） - 軽微なコンパイルエラーやアノテーションが不足していることがある。
- ユニットテストモジュールを自動生成できるIDEは、2025年3月時点ではJetBrains IDEsとVisual Studio Codeのみ。
＜今後改善を期待する点＞
- プロジェクト全体でテストモジュールを設定ファイルまで一式生成できると、よりAIに任せられる範囲が広がる。
- コマンドベースでユニットテストモジュールを生成できれば、AWS CodeBuild上でコマンド実行してテストモジュールを作成し、そのままカバレッジ実行が実行できる。これにより、ユーザはローカル環境で実装したものを外部リポジトリにコミットするだけで、AWS CodePipelineで単体テスト以降を自動的に実施できるようになります。
まとめ
Amazon Q Developer プラグインは無料で利用でき、優れた推論精度でユニットテストモジュールを自動生成してくれます。2025年3月時点の推論レベルでも、上記考慮点を踏まえておけば、大きく単体テストの工数を削減できるのではないでしょうか。
今後、推論モデルの精度が向上することで、ユニットテスト全体を自動生成でき、DevOpsのCIの幅が広がっていくと考えています。
富士ソフトのAWS関連サービスについて、詳しくはこちら
アマゾンウェブサービス(AWS)
