利益:
- AI を使用して単体テスト、エッジ ケース、カバレッジ ギャップ分析を作成する機能
- コードの現在の動作ではなく、仕様に基づいてテストの期待値を出力する機能
- エラーを挿入することでテストが実際に保護するかどうかをテストする機能
テストの作成は、ほとんどの開発者が後回しにしてしまう、最も価値を生み出すタスクの 1 つです。優れたテスト スイートは、コードが期待どおりに動作することを証明し、将来の変更に対する生命線となります。問題は、テストの作成は反復的で時間がかかることであり、まさに AI が威力を発揮する種類の作業です。ただし、落とし穴があります。AI は多くの場合、コードの本来の動作ではなく、コードの既存の動作をテストします。この違いを管理することがこの単元の本質です。
この単元では、単体テスト (機能を単独で分離してテストするテスト)、エッジケース テスト、および AI を使用したテスト データの生成について学びます。テストカバレッジのギャップを埋める。そしてなぜAIテストを盲目的に信頼することが危険なのか。
テストの 2 つの側面: 動作の修正と検証
テストは 2 つの異なる目的に使用できます。 1 つ目は検証です。コードが正しいかどうか、仕様に準拠しているかどうかをテストします。 2 つ目は回帰保護です。今日のコードの動作がフリーズするため、明日誰かが誤ってコードを変更すると、テストが中断されて通知されます。
AI は後者を非常に得意としています。コードを調べて、「現在実行していること」をテストするケースを生成します。しかし、コードが最初から間違っていた場合、AI はその間違った動作を「正しい」ものとして固定することができます。したがって、AI が生成する各テストのアサーションを確認する必要があります。「コードは 42 を返し、テストは 42 を期待している」ということは、42 が正しい答えであることを意味するわけではありません。
注意: AI がテストに合格しても、コードが「機能している」ことを意味するわけではありません。それは単に「AIの期待どおりに動作する」ということです。期待が正しいかどうかは、仕様を見て判断します。
ステップバイステップ: AI を使用して堅牢なテストを作成する
- コードだけでなく仕様も記載してください。 「この関数はこうするべきだ」という情報を追加すると、AI は正しい期待値を書き込むことができます。コードを提供するだけで、現在の動作がテストされます。
- エッジケースを尋ねてください。空、null、ゼロ、負、大きすぎる、不正な形式、同時実行 - 明示的に幸せな道から外れていると主張します。
- テストのフレームワークとスタイルを指定します。 「pytest を使用する」、「Arrange-Act-Assert パターン」、「各テストで 1 つのことをテストする」など。
- 期待値（アサーション）を確認します。各アサートが正しい値をチェックする仕様と比較してください。
- 範囲内のギャップを埋めます。既存のテストを提示し、「どのブランチとケースがテストされていないのか?」と尋ねます。尋ねさせる。次に、生成された追加のテストを検証します。
ミニケース3個
ケース 1 — カバレッジ 52% から 85%。 1 つのサービス モジュールのテスト カバレッジは 52% でした。チームは既存のテストを AI に供給し、テストされていないブランチをリストしてそれらのテストを生成させました。人間によるレビューにより、カバー率は 85% に増加しました。その過程で、AI はこれまでテストされたことのないバグ ブランチ内の実際のバグ (間違ったエラー コードを返すパス) を発見しました。
ケース 2 — 誤った期待に固執する罠。お金の丸め機能は実際には間違っていました。 2.675 を 2.67 に四捨五入する代わりに、2.68 ではなく 2.67 を四捨五入していました。 AI はコードを見て、assert Round_money(2.675) == 2.67 と書き、エラーを「true」として凍結しました。開発者が仕様を読んだとき、予想を修正し、本当のバグを発見しました。コードではなくルールをテストすることで違いが生じました。
ケース 3 — エッジ状態の爆発。 AI に日付範囲関数の「エッジケース」のみを要求する場合。開始=終了、逆間隔、閏年 2 月 29 日、異なるタイム ゾーン、ヌル間隔など、8 つのケースが生成されました。このうち 2 つ (逆間隔と閏年) が実際にエラーを引き起こしていました。これらのケースを手動で検討することはスキップされることがよくあります。ここでは AI が「エッジケースのブレインストーミング」パートナーになりました。
4 つのコピー可能なテンプレート
仕様ベースのテスト生成:
役割: テストを作成する開発者。フレームワーク: {{pytest/JUnit/Jest...}}。関数が行うべきこと (仕様): {{rule}}次の関数のテストを作成します。コードの現在の出力ではなく、仕様に従って期待値を記述します。ハッピーパス + 少なくとも 4 つのエッジケースを追加します。各テストで 1 つのことをテストし、わかりやすい名前を使用します。 {{関数}}
エッジケースのブレーンストーミング:
この関数のテストで試行する必要があるエッジ/障害ケース (null、null、ブレークポイント、不正な形式、同時実行性、外部エラー) をリストします。各ケースについて: 入力、予期される動作。まだコードは書かないでください。リストするだけにしてください。{{function}}
カバレッジギャップ分析:
以下に機能と利用可能なテストを示します。どの分岐、条件、ケースがテストされていませんか?欠陥をリストし、欠陥のみを対象とする新しいテストを作成します。既存のものを繰り返さないでください。関数:{{function}}テスト:{{existing_tests}}
テストデータ/モックオブジェクトの生成:
{{関数/サービス}} テストの現実的なテスト データを生成します。有効なサンプル、境界サンプル、無効なサンプルを個別に生成します。外部依存関係 {{X}} の単純なモック動作を提案します。真の機密データ/PII を使用する。偽のデータを生成します。
弱いプロンプト / 強いプロンプト
弱: 「この関数のテストを作成します。」
強力: 「pytest を使用。関数 apply_discount(total,percent) — ルール: 割引は 0% ～ 30% である必要があり、範囲外の場合は ValueError をスローする必要があり、結果は小数第 2 位に四捨五入する必要があります。(コードではなく) このルールによって期待値を書き込みます。ハッピー パス + これらのエッジ ケース: 0%、30%、31% (エラー)、負、合計 = 0。[コード]」
彼は強力なリリース ルールを与え、「コードではなくルールに従って期待値を書きなさい」と言っています。この一文で、不正行為を修正する AI の罠が閉じられます。
テストの種類
AIの貢献
人間の制御
ハッピーロードユニットテスト
速いスケルトン
その期待は正しいでしょうか？
エッジケース
広範なブレインストーミング
無関係なものを排除する
スコープのギャップを埋める
スキップされたブランチを検索します
重要性を確認する
テストデータ/モック
リアルなサンプルを作成します
PII なし、リアリズム制御
テストは品質を管理するものであり、保証するものではありません
テスト カバレッジが高いと信頼感が得られますが、誤解を招く可能性もあります。カバレッジ 100% は、「すべての行が正しい」ではなく、「すべての行が実行された」ことを意味します。 AI を使用するとカバー範囲を拡大するのは簡単です。本当の価値は、意味のある期待を書くことにあります。テストの価値は、コードが壊れたときに警告を発して警告する機能です。そのため、AI が生成するテストは、「コードが変更されると本当に壊れるのか?」という質問に基づいています。質問でテストしてください。意図的に改行し、テストの中断 (突然変異のアイデア) が表示されることは、テストが機能したことの証拠となります。
ヒント: AI が作成したテストが機能するかどうかを確認するには、コードに小さなバグを作成し (+ を - に変更するなど)、テストが中断されるかどうかを確認します。壊れなければ、そのテストはあなたを守ってくれません。
よくある間違い
- ルールを与えずにテストを要求する。モデルは現在の動作を凍結します。エラーを「true」として修正します。
- 期待を読まずに受け入れる。アサーションが正しい値をチェックしているかどうかを確認しないと、テストは誤解を招きます。
- 幸せな道を試しているだけです。実際のエラーはマージンに存在します。エッジケースについては明示的に尋ねてください。
- 目的と範囲を間違えている。パーセンテージが高くても、正しい動作が保証されるわけではありません。
- 実データ/非表示データをテストデータとして作成します。顧客データや機密情報をテストや保管場所に入れないでください。合成データを生成します。
要約すると
AI は、テストの作成に伴う反復的な負担の多くを軽減します。AI は、高速なスケルトン、エッジ ケースの大きなリスト、カバレッジ ギャップ分析を生成します。しかし、最も重要な点は期待です。AI はコードの現在の動作をテストする傾向がありますが、テストは仕様に従って記述される必要があります。ルールを与え、期待をチェックし、エッジケースを適用し、バグを挿入することでテストが実際に保護するかどうかをテストします。テストカバレッジはツールであり、目標ではありません。
アプリケーションタスク
関数を選択し、まずそのコードを与えるだけで AI にテストを出力します。期待に注意してください。次に、同じ関数の仕様 (必要な動作) を指定してテストを再度印刷します。 2 つのテスト セットの期待値を比較してください。違いはありますか。どちらが本当のバグを明らかにしますか?最後に、コードに意図的なバグを追加し、テストの中断を確認することで、生成されたテストの 1 つが機能することを確認します。
チェックリスト
- [ ] テストが動作を修正するためのものなのか、動作を検証するためのものなのかを区別します。
- [ ] テストを依頼するときは、コードではなく、定めるべきルール (仕様) を渡します。
- [ ] 生成された各アサーションを仕様と比較します。
- [ ] エッジケースと失敗ケースを明示的にリクエストします。
- [ ] 私はカバレッジの割合を目標ではなく手段として捉えています。
- [ ] エラーを挿入することで、テストが実際に保護するかどうかをテストします。