論文の概要: How Far Are We from Detecting Flaky Tests? On the Limits of Code-Based Detection

• arxiv url: http://arxiv.org/abs/2607.09345v1
• Date: Fri, 10 Jul 2026 12:24:25 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-07-13 14:47:12.838472
• Title: How Far Are We from Detecting Flaky Tests? On the Limits of Code-Based Detection
• Title（参考訳）: 欠陥検出からどこまで遠いのか? コードベース検出の限界について
• Abstract要約: 燃えるようなテストは同じコードバージョンでパスしてフェールし、テスト結果のシグナルを弱める。 コードベースのフレキネス検出器は強力なベンチマーク結果を報告しているが、実際の使用は限られている。 フレキネスはテストコードの静的な特性ではなく、テストが不安定かどうかを決定するのに必要な情報が欠けていることが多い、と私たちは主張する。
• 参考スコア（独自算出の注目度）: 41.369102837712795
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Flaky tests pass and fail on the same code version, weakening the signal of test results and disrupting continuous integration (CI) pipelines. Code-based flakiness detectors report strong benchmark results, yet their use in practice remains limited. We argue that the field is studying the wrong problem: Flakiness is not a static property of test code, which often lacks the information needed to decide whether a test is flaky. Analyzing three code-based detectors operating on test code, we found that widely used benchmarks contain shortcuts that inflate reported F1 scores and that evaluation protocols overstate generalizability. To control for these shortcuts, we curated two datasets. The first, C-IDoFT (54,468 unit tests from 57 GitHub projects), keeps a developer-confirmed subset of IDoFT's flaky tests and rebuilds only the non-flaky class from repeated executions instead of fixed versions of flaky tests. C-IDoFT is a controlled counterfactual, not a benchmark for reuse. Our CodeBERT reimplementations of two published detectors scored far above its constant baselines under the published cross-validation protocol but no better than them once projects were separated. The high scores rested on the labeling shortcut and the evaluation protocol, not on the test code. On FlakeBench, a benchmark restricted to flakiness types typically recognizable from test code, and the same project-disjoint protocol, the models identified nearly all flaky tests. The second dataset, mined from CI logs, contains 86 flaky end-to-end tests that passed and failed on the same commit. The test code and CI log yielded a cause for 42% of them; the other 58% required further execution evidence. Rather than abandoning flakiness prediction, we reframe it around whether an observed failure is flaky and how likely a test is to fail given its execution environment. Our datasets and CI-mining method support this direction.
• Abstract（参考訳）: 燃えるようなテストは同じコードバージョンでパスしてフェールし、テスト結果のシグナルを弱め、継続的インテグレーション(CI)パイプラインを破壊します。 コードベースのフレキネス検出器は強力なベンチマーク結果を報告しているが、実際の使用は限られている。 フレキネスはテストコードの静的プロパティではなく、テストが不安定かどうかを決定するのに必要な情報がないことが多い。 テストコード上で動作している3つのコードベース検出器を解析したところ、広く使用されているベンチマークには、F1スコアをインフレーションするショートカットと、評価プロトコルがオーバーステートの一般化性を含んでいることがわかった。 これらのショートカットを制御するために、2つのデータセットをキュレートした。 最初のC-IDoFT(57のGitHubプロジェクトから54,468のユニットテスト)は、開発者が確認したIDoFTの不安定なテストのサブセットを保持し、不安定なテストの固定バージョンではなく、繰り返し実行される実行から非不安定なクラスのみを再構築する。 C-IDoFTは制御された偽物であり、再利用のベンチマークではない。 CodeBERTが公開した2つの検出器の再実装は、公表されたクロスバリデーションプロトコルの下で一定のベースラインをはるかに上回りました。 高いスコアは、テストコードではなく、ラベリングショートカットと評価プロトコルに残っていた。 FlakeBenchでは、一般的にテストコードから認識可能なフレキネスタイプに制限されたベンチマークと、同じプロジェクト・ディスジョイントプロトコルを使用して、ほぼすべてのフレキネステストを特定した。 CIログから抽出された第2のデータセットには、同じコミットでパスして失敗した86の不安定なエンドツーエンドテストが含まれている。 テストコードとCIログは42%が原因となり、残りの58%はさらなる実行証拠を必要とした。 フレキネスの予測を捨てるのではなく、観察された失敗が不安定なのか、その実行環境からテストが失敗する可能性が高いのかを、再設定します。 私たちのデータセットとCIマイニングメソッドは、この方向をサポートします。

関連論文リスト

• ExecCritic: Learn to Test, Test to Improve for Coding Agents [68.42713285082912]
  実行時のフィードバックは、コーディングエージェントを正しいリポジトリの修復に導くことができますが、テストが問題によって要求された振る舞いをキャプチャした場合のみです。 ExecCriticを導入し、テスト-検証-修正足場と、その中のトレーニングエージェントのためのロール固有の強化学習レシピを組み合わせる。 テストエージェントが独立してリポジトリネイティブなテストを生成し、フェイルクローズされたハーネスがそれらを調整して凍結し、リカバリエージェントがテストを変更することなく、ソースコードを実行フィードバックから修正する。
  論文  参考訳（メタデータ） (2026-09-08T17:53:37Z)
• Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution [20.606877071567958]
  テスト進化のための最初のプロジェクトレベルのベンチマークであるTEBenchを紹介します。 TEBenchをDefects4Jプロジェクト上で4段階のパイプラインで構築する。 3つの産業エージェントフレームワークにまたがる7つの構成を評価する。
  論文  参考訳（メタデータ） (2026-05-07T12:31:09Z)
• Reduction of Test Re-runs by Prioritizing Potential Order Dependent Flaky Tests [0.5798758080057375]
  不安定なテストは、予測不可能な振る舞いのため、自動化されたソフトウェアテストの信頼性を損なう可能性がある。 フラキーテストの一般的なタイプは、順序依存(OD)テストである。 本稿では,潜在的なODテストの優先順位付け手法を提案する。
  論文  参考訳（メタデータ） (2025-10-30T06:17:30Z)
• Studying the Impact of Early Test Termination Due to Assertion Failure on Code Coverage and Spectrum-based Fault Localization [48.22524837906857]
  本研究は,アサーション障害による早期検査終了に関する最初の実証的研究である。 6つのオープンソースプロジェクトの207バージョンを調査した。 以上の結果から,早期検査終了は,コードカバレッジとスペクトルに基づく障害局所化の有効性の両方を損なうことが示唆された。
  論文  参考訳（メタデータ） (2025-04-06T17:14:09Z)
• GPT-HateCheck: Can LLMs Write Better Functional Tests for Hate Speech Detection? [50.53312866647302]
  HateCheckは、合成データに対してきめ細かいモデル機能をテストするスイートである。 GPT-HateCheckは,スクラッチからより多彩で現実的な機能テストを生成するフレームワークである。 クラウドソースのアノテーションは、生成されたテストケースが高品質であることを示しています。
  論文  参考訳（メタデータ） (2024-02-23T10:02:01Z)
• Taming Timeout Flakiness: An Empirical Study of SAP HANA [47.29324864511411]
  不安定なテストは回帰テストに悪影響を及ぼします。 テストタイムアウトは、このような不安定なテストの失敗に寄与する要因のひとつです。 テストのフレキネス率は、繰り返しテストの実行回数によって49%から70%の範囲である。
  論文  参考訳（メタデータ） (2024-02-07T20:01:41Z)
• 230,439 Test Failures Later: An Empirical Evaluation of Flaky Failure Classifiers [9.45325012281881]
  不安定なテストは、コードの変更がなくても、決定論的にパスまたはフェールできるテストである。 欠陥が原因でテストが失敗したのか、それともバグを検知したのか、どうやって簡単に判断できるのか?
  論文  参考訳（メタデータ） (2024-01-28T22:36:30Z)
• The Effects of Computational Resources on Flaky Tests [9.694460778355925]
  不安定なテストは、不確定にパスし、変更のないコードで失敗するテストである。 リソースに影響されたFraky Testsは、テストの実行時に利用可能なリソースを調整することで、かなりの数のFraky-test障害を回避することができることを示している。
  論文  参考訳（メタデータ） (2023-10-18T17:42:58Z)
• Sequential Kernelized Independence Testing [77.237958592189]
  我々は、カーネル化依存度にインスパイアされたシーケンシャルなカーネル化独立試験を設計する。 シミュレーションデータと実データの両方にアプローチのパワーを実証する。
  論文  参考訳（メタデータ） (2022-12-14T18:08:42Z)

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

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