エージェント生成コードのためのPytest：実践的な具体的テスト戦略

Compass をご紹介 — Slack 向けの Dagster 新 AI データアナリストです。質問を即座に信頼できるインサイトに変換します。今すぐ Compass をお試しください → データアセットが最も得意とするところを、データアセットがどのように連携して機能するかを描いたアニメーション付きナレーションストーリーで発見しましょう。今すぐ視聴 → Dagster の利用を開始 | サインイン エージェントがテストコードを作成する際、正しさと同様に意図も重要です。明確なテストレベル、推奨されるパターン、そして明示的なアンチパターンを定義することで、自動化に合わせてスケーラブルかつ高速で信頼性の高い Pytest スイートを生成するために必要な構造をエージェントに提供します。 以前の投稿では、エージェントによって生成された Python コードが常に「品格ある」ものとなるよう、私たちが内部で使用しているいくつかのスタイル上の選択について議論しました。スタイル、構造、そして Python の慣習的な書き方をカバーするこれらのルールは、コードの多くが機械支援によって作成される場合でも、一貫して高品質なコードベースを維持するのに役立ちます。 しかし、支援を受けながらコードを作成する場合、テストについてもエージェントに同じ基準を適用する必要があります。実際には、微妙なエラーや長期的なメンテナンス上の問題を引き起こすことなく、エージェントに対してテストの設計と記述方法をどのように指示するかを明確にする必要があります。 これには、「良いテスト」とはどのようなものかだけでなく、いつテストを書くべきか、異なる状況でどの種類のテストが適切か、そしてどのパターンが禁止されるかを定義する、リポジトリ全体にわたるテスト戦略が必要です。 つまり、テストの書き方を定義するルールとロジックを提供し、その決定を推論に委ねてはならないのです。 私たちのテスト戦略はスキルを中心に設計されています。これらのスキルの詳細の多くは、いくつかの微妙な変更を加えることで、あらゆるリポジトリに適用可能です。しかし、実際のテスト戦略に入る前に、これらのテストがワークフロー内でどのように実行されるかについて議論しておくことが重要です。 テスト作成エージェントは、アプリケーションコードを生成するエージェントと同じ権限や文脈を使用しません。テスト生成は、隔離されたコンテキストウィンドウ内で意図的に制限された役割を持つサブエージェントとして実行されます。テスト作業をサブエージェントに限定することで、エージェントがテストの失敗を「修正」するために、テスト対象のコードを微妙に調整するという一般的な失敗モードを防ぎます。 そのサブエージェント内では、各スキルは特定の関数に対するカバレッジを追加する、報告されたバグを再現する、または明確化のために既存のテストをリファクタリングするなど、狭いタスクを表します。要求が制限されたスキルとして表現できない場合、それは通常、自動化されたテストパスには属しません。 最後に、私たちは文脈を非常に意図的に管理しています。テストサブエージェントはタスク固有のコンテキストで実行され、実行間を通じて履歴を蓄積しません。これにより、推測的なテストや、過去の失敗への偶発的な依存、非推奨の動作に基づくアサーションが回避されます。各呼び出しは単独で成立可能であり、可読性があり、意図的かつ決定論的なテストを生成する必要があります。 私たちは単純なワークフローから始めます。src ディレクトリの下に導入された新しいロジックに対しては、必ずテストを作成すべきです。エージェントが現在の作業セッションで実際に実装されているコードのみに対してテストを書くべきであることを明確にしています。 エージェントにテスト対象とする範囲を限定することで、ノイズを減らし、テストがコードベースに対する実際かつ意図的な変更を追跡するように保証します。 テスト可能な新規コードの範囲を制限した後、新機能の開発のためのコードとバグ修正のためのコードを区別し始めます。 バグ修正は、より定型的な手順に従います： - バグを再現する失敗するテストを書く。 - テストを実行し、それが現在成功することを確認する。 - 回帰テストとしてそのテストを残す。 新機能については、テスト駆動開発（TDD）が推奨されます。適切なテストは機能と共に含まれることを期待しますが、どのテストを書くか、またどのレベルで書くかという具体的な詳細は、やや洗練されたものになります。 リポジトリの文脈の一部として、私たちは明示的なテストレベルをいくつか定義しています。各レベルについて、その目的と、全体のテストスイートにおいて占めるべきおおよその割合を説明します。これにより、エージェントに対して、ほとんどのテストがどこに存在すべきかという強力な事前知識（prior）を与えます。 例えば、あるコードベースでは、テスト用に特別に構築されたインフラのフェイク実装に対して、テストの大多数が記述されています。リファクタリング時に脆くなりやすく、パフォーマンスや安全性の問題を引き起こす可能性があるため、モックを過度に使用するアプローチよりも、この手法を好みます。 私たちのテストレベルを表したテーブルは、ビジネスロジックテスト（レベル 4）がテストコードベースの大多数を占めるべきであることをエージェントに指示することで、この優先順位を反映しています。 この表は、分布を明示することで意図を符号化し、新しいテストをどこに配置すべきかをエージェントにシグナルを送ります。 各レベルのルーティングは、testing-strategy.md スキル内のロジックによって処理され、ここでは特定のテスト戦略がいつ、なぜ選択されるべきかに関する詳細を含んでいます: レイヤー 4: フェイクに対するビジネスロジックテスト（多数派） 目的：高速なインメモリフェイクを使用してアプリケーションロジックを徹底的にテストする。 場所：tests/unit/services/, tests/unit/, tests/commands/ いつ記述するか：すべての機能とバグ修正に対して。これがデフォルトのテストレイヤーです。 理由：高速、信頼性が高く、容易にデ

エージェント生成コードのためのPytest：実践的な具体的テスト戦略

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト