AIに書かせたテストコードをレビューするとき最初に見る3点|JUnitで確認したいことをズラさない
AIにテストコードを書かせたとき、自分が最初に見るのは「JUnitの書き方がきれいか」より先に、「そのテストは何を確認したいんやろ」と1文で言えるかです。
ここが曖昧なままだと、ちゃんとテストしているように見えても、実装をなぞっただけの都合のいい確認になりやすいです。
この記事では、AIに書かせたテストコードをレビューするときに、自分が最初に見る3点だけに絞って整理します。最初から網羅性を見にいくというより、ズレやすい所を先に潰すための入口です。
先に結論: 最初は「意図・抜け・壊れやすさ」を見る
AIに書かせたテストコードをレビューするとき、最初に見る点は次の3つです。
- そのテストは何を確認しているのか1文で言えるか
- 正常系だけでなく、異常系や境界値の抜けがないか
- 実装に寄りすぎていて、少しの修正で壊れやすいテストになっていないか
この3つが見えるだけでも、AIが書いたテストを「それっぽいコード」として流すのではなく、確認の道具として見やすくなります。
1. そのテストは何を確認しているのか明確か
まず一番見るのは、テスト名や assertion を読んだときに、「このテストは何を確かめたいのか」がすぐ言えるかです。
たとえば次のようなテストは、一見それっぽく見えても、何を確認したいのかが少しぼやけやすいです。
@Test
void testCreateUser() {
User user = service.create("yamada");
assertEquals("yamada", user.getName());
assertEquals(Role.USER, user.getRole());
assertNotNull(user.getCreatedAt());
}
このコード自体が間違いというより、何が本題の確認なのかを読んだ瞬間に言いづらいのが気になります。
自分はここで、たとえば「ユーザー作成時に名前が保持されることを確認したい」「初期ロールが USER になることを確認したい」のように、確認対象を日本語で言い直せるかを見ます。
1つのテストで複数のことを見すぎているなら、テストを分けた方が読みやすいことも多いです。
2. 異常系や境界値が抜けたままになっていないか
AIに書かせると、正常系はきれいに出てきても、異常系や境界値が薄いまま終わることがあります。
たとえば、登録処理なら「正常に登録できる」だけでなく、「null や空文字のときにどうなるか」「上限を超えた入力でどうなるか」も見たいことが多いです。
@Test
void nullNameのとき例外になる() {
assertThrows(IllegalArgumentException.class, () -> service.create(null));
}
assertThrows は、想定した例外が発生することを確認するための assertion です。単に落ちればよいのではなく、どの例外を期待しているかを明示してテストします。
AIが書いた正常系テストだけで安心すると、後で仕様の抜けに気付きやすいです。最初のレビューでは、この処理で失敗させたい入力が抜けていないかを最低限見ています。
3. 実装依存が強すぎて壊れやすくなっていないか
もう1つ見るのは、そのテストが仕様確認ではなく、実装の細かい書き方に引っ張られすぎていないかです。
AIは今ある実装をなぞるのが得意なので、内部メソッドの呼び方や途中状態まで細かく固定したテストを書いてくることがあります。
もちろんモックや呼び出し回数の確認が必要な場面はあります。ただ、最初に全部そこへ寄ると、少しリファクタリングしただけで壊れるテストが増えやすいです。
自分はここで、「そのテストは利用者から見える振る舞いを確認しているか」「失敗したときに何が壊れたか追いやすいか」を見ます。
なお、サンプルでは読みやすさのため日本語のテスト名を書いていますが、実務では英語名で統一するケースが一般的です。
最初に見る3点を表でまとめる
まず見る点を一覧にすると次の通りです。
| 見る点 | 確認したいこと |
|---|---|
| 意図 | そのテストが何を確認したいのか1文で言えるか |
| 抜け | 正常系だけでなく異常系や境界値も最低限見ているか |
| 壊れやすさ | 実装依存が強すぎず、変更に対して過剰に脆くないか |
まとめ
AIにテストコードを書かせること自体は便利ですが、そのまま通す前に、人がどこを見るかはまだかなり大事やと思っています。
自分は最初に、何を確認しているか、異常系や境界値が抜けていないか、実装依存が強すぎないかの3点から見ます。最初から完璧に見るというより、この3点でズレを早めに見つける感覚です。
次に読みたい関連記事
- 文系出身エンジニアがJUnitで最初に詰まりやすい3つのポイント
- JUnit 5のアサーション・アノテーションまとめ|assertEquals/assertThrows/@BeforeEachの使い分け
- JaCoCoでカバレッジレポートを出すbuild.gradle設定まとめ
JUnit 5、Mockito、DBUnit、Spring Bootを使ったテスト実装を、基礎から実践的な流れで整理したい方向けにUdemy講座も用意しています。
講座はこちらです。
JUnit 5完全攻略: Javaのテスト実装を基礎から実務レベルまで学ぶ
コメント
0 件のコメント :
コメントを投稿