論文の概要: Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution

• arxiv url: http://arxiv.org/abs/2605.06125v1
• Date: Thu, 07 May 2026 12:31:09 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-05-08 22:27:11.771431
• Title: Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution
• Title（参考訳）: ブレーク、ステール、ミス? プロジェクトレベルテスト進化におけるコーディングエージェントのベンチマーク
• Authors: Ye Shang, Quanjun Zhang, Haichuan Hu, Chunrong Fang, Liang Xiao, Zhenyu Chen,
• Abstract要約: テスト進化のための最初のプロジェクトレベルのベンチマークであるTEBenchを紹介します。 TEBenchをDefects4Jプロジェクト上で4段階のパイプラインで構築する。 3つの産業エージェントフレームワークにまたがる7つの構成を評価する。
• 参考スコア（独自算出の注目度）: 20.606877071567958
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: As production code evolves, the test suite must co-evolve to remain effective. Existing benchmarks for test evolution operate at method-level granularity with pre-paired inputs, bypassing the task of locating affected tests from the full project and excluding the need for new tests entirely. We present TEBench, the first project-level benchmark for test evolution. Given a project repository and a code-changing commit, TEBench requires systems to autonomously identify tests requiring modification, determine where new tests are needed, and produce the corresponding test patch. We construct TEBench through a four-stage pipeline over Defects4J projects, curating 314 task instances from 10 projects with developer-written ground truth. Each instance is annotated with one or more of three evolution types: Test-Breaking (tests that fail), Test-Stale (tests that pass but no longer meaningfully validate updated behavior), and Test-Missing (new tests needed for introduced behavior). We evaluate seven configurations spanning three industrial agent frameworks (Claude Code, Codex CLI, OpenCode) and six base models, alongside a heuristic baseline. All seven configurations converge on an identification F1 of 45.7% to 49.4%, revealing a shared performance ceiling across both frameworks and base models. Test-Stale is the most challenging type, averaging F1 around 36%, since configurations rely on execution failure signals and lack proactive semantic reasoning. On the update task, configurations produce highly executable test modifications whose surface form diverges substantially from ground truth. Trajectory analysis reveals a reactive "execute-fail-fix" loop that succeeds for breaking tests but structurally cannot address stale or missing tests. TEBench is available at https://github.com/iSEngLab/TEBench with a leaderboard at https://tebench-leadership.vercel.app.
• Abstract（参考訳）: プロダクションコードが進化するにつれて、テストスイートは効果的なままでいなければならない。 既存のテスト進化のベンチマークは、事前にペアリングされた入力でメソッドレベルの粒度で動作し、影響のあるテストをプロジェクト全体から特定し、新しいテストを完全に排除するタスクをバイパスする。 テスト進化のための最初のプロジェクトレベルのベンチマークであるTEBenchを紹介します。 プロジェクトリポジトリとコード変更コミットが与えられた場合、TEBenchはシステムに対して、修正が必要なテストを自律的に識別し、新しいテストが必要な場所を特定し、対応するテストパッチを生成するように要求する。 TEBenchはDefects4Jプロジェクト上の4段階のパイプラインを通じて構築され、10のプロジェクトから314のタスクインスタンスを、開発者記述の真理でキュレートします。 各インスタンスには、テストブレーキング(失敗するテスト)、テストステアリング(パスするが、更新された振る舞いを有意に検証しないテスト)、テストミス(導入された振る舞いに必要な新しいテスト)の3つのタイプの1つまたは2つが注釈付けされている。 3つの産業エージェントフレームワーク(Claude Code、Codex CLI、OpenCode)と6つのベースモデルにまたがる7つの構成と、ヒューリスティックなベースラインを評価した。 7つの構成はすべて45.7%から49.4%の識別F1に収束し、フレームワークとベースモデルの両方で共通のパフォーマンス天井が明らかになった。 Test-Staleは最も難しいタイプで、設定が実行障害信号に依存しており、アクティブなセマンティック推論が欠けているため、F1の平均は36%である。 更新タスクでは、表面形状が基底真理から大きく分岐する高度に実行可能なテスト修正を生成する。 軌道分析により、リアクティブな"実行時欠陥修正"ループが明らかになり、テストの破壊に成功するが、構造的には古いテストや欠落テストには対処できない。 TEBenchはhttps://github.com/iSEngLab/TEBenchで、リーダーボードはhttps://tebench- Leadership.vercel.app.comで入手できる。

関連論文リスト

• An Iterative Test-and-Repair Framework for Competitive Code Generation [9.137158235106943]
  大規模言語モデル(LLM)はコード生成において顕著な進歩を遂げているが、競争力のあるプログラミングは依然として課題である。 近年,強化学習(RL)と実行フィードバックによるコード生成が改良されている。 より最近のフレームワークCUREでは、テスト生成をトレーニングプロセスに組み込んで、CoderとTesterを1つのモデルで共同でトレーニングしている。
  論文  参考訳（メタデータ） (2026-04-07T08:00:54Z)
• Are Benchmark Tests Strong Enough? Mutation-Guided Diagnosis and Augmentation of Regression Suites [49.16055123488827]
  十分に強力なテストスイートは、報告された成功率を膨らませながら、妥当だが意味的に正しくないパッチを認めることができる。 STINGは、意味的に変化するプログラムの変種を診断ストレス要因として利用する、ターゲットテスト拡張のためのフレームワークである。 STINGは211インスタンスにまたがる1014の検証テストを生成し、パッチリージョンラインとブランチカバレッジを10.8%、9.5%向上させた。
  論文  参考訳（メタデータ） (2026-04-02T01:13:40Z)
• WebTestBench: Evaluating Computer-Use Agents towards End-to-End Automated Web Testing [57.7131457251794]
  エンドツーエンドの自動Webテストを評価するベンチマークであるWebTestBenchを紹介します。 テストプロセスを2つのカスケードサブタスク、チェックリストの生成と欠陥検出に分解し、WebTesterを提案する。 以上の結果から,現在のコンピュータ利用エージェント能力と産業レベルの展開要求との間に大きなギャップがあることが判明した。
  論文  参考訳（メタデータ） (2026-03-26T09:27:29Z)
• Nexus: Execution-Grounded Multi-Agent Test Oracle Synthesis [57.40527331817245]
  非回帰テストにおけるテストオラクル生成は、ソフトウェア工学における長年の課題である。 この課題に対処するための新しいマルチエージェントフレームワークであるNexusを紹介します。
  論文  参考訳（メタデータ） (2025-10-30T12:20:25Z)
• ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases [58.411135609139855]
  タスク完了のための「ショートカット」は、大規模言語モデルの信頼性評価と展開に重大なリスクをもたらす。 我々は,LLMエージェントがテストケースを利用するための正当性を測定するベンチマークフレームワークであるImpossibleBenchを紹介する。 実践的なフレームワークとして、ImpossibleBenchは単なる評価ではなく、汎用的なツールである。
  論文  参考訳（メタデータ） (2025-10-23T06:58:32Z)
• Intention-Driven Generation of Project-Specific Test Cases [45.2380093475221]
  検証意図の記述からプロジェクト固有のテストを生成するIntentionTestを提案する。 13のオープンソースプロジェクトから4,146件のテストケースで,最先端のベースライン(DA, ChatTester, EvoSuite)に対してIntentionTestを広範囲に評価した。
  論文  参考訳（メタデータ） (2025-07-28T08:35:04Z)
• ProjectTest: A Project-level LLM Unit Test Generation Benchmark and Impact of Error Fixing Mechanisms [48.43237545197775]
  単体テスト生成はLLMの有望かつ重要なユースケースとなっている。 ProjectTestは、Python、Java、JavaScriptをカバーするユニットテスト生成のためのプロジェクトレベルのベンチマークである。
  論文  参考訳（メタデータ） (2025-02-10T15:24:30Z)
• AugmenTest: Enhancing Tests with LLM-Driven Oracles [2.159639193866661]
  AugmenTestは、大規模な言語モデルを活用して、テスト中のソフトウェアの利用可能なドキュメントに基づいて、正しいオーラクルを推測するアプローチである。 AugmenTestには4つのバリエーションがある: Simple Prompt、Extended Prompt、ジェネリックプロンプト付きRAG(テスト中のクラスやメソッドのコンテキストなしで)とSimple Prompt付きRAG。 結果は、最も保守的なシナリオでは、AugmenTestのExtended PromptがSimple Promptを一貫して上回り、正しいアサーションを生成するために30%の成功率を達成したことを示している。
  論文  参考訳（メタデータ） (2025-01-29T07:45:41Z)
• TestGenEval: A Real World Unit Test Generation and Test Completion Benchmark [24.14654309612826]
  TestGenEvalは、1,210のコードから68,647のテストと、11の保守されたPythonリポジトリにまたがるテストファイルペアで構成されている。 初期テストのオーサリング、テストスイートの補完、コードカバレッジの改善をカバーしている。 パラメータは7Bから405Bまで様々である。
  論文  参考訳（メタデータ） (2024-10-01T14:47:05Z)
• Observation-based unit test generation at Meta [52.4716552057909]
  TestGenは、アプリケーション実行中に観察された複雑なオブジェクトのシリアライズされた観察から作られたユニットテストを自動的に生成する。 TestGenは518のテストを本番環境に投入し、継続的統合で9,617,349回実行され、5,702の障害が見つかった。 評価の結果,信頼性の高い4,361のエンドツーエンドテストから,少なくとも86%のクラスでテストを生成することができた。
  論文  参考訳（メタデータ） (2024-02-09T00:34:39Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。