論文の概要: Evaluating Shaker for Flaky Test Detection in Python Projects
- arxiv url: http://arxiv.org/abs/2609.25528v1
- Date: Tue, 22 Sep 2026 00:48:48 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-09-23 18:04:04.165469
- Title: Evaluating Shaker for Flaky Test Detection in Python Projects
- Title（参考訳）: Pythonプロジェクトにおけるフレキシブルテスト検出のためのシェーカーの評価
- Abstract要約: 不安定なテストは、変更のないコードで非決定的にパスまたはフェールする。
Shakerはリソース競合を注入し、非決定性を増幅することでそれらを検出する。
本稿では,Python 用 Shaker の最初の経験的評価について述べる。
- 参考スコア（独自算出の注目度）: 0.856431962593089
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Flaky tests pass or fail non-deterministically on unchanged code, eroding trust in test suites and inflating the cost of every failure. Shaker detects them by injecting resource contention (CPU, memory, and I/O stress) to amplify non-determinism caused by concurrent execution, and was reported to detect 95% of the flaky tests in a Java and Android benchmark against 37.5% for plain re-execution (ReRun). We present the first empirical evaluation of Shaker for Python. Drawing non-order-dependent flaky tests from the ground-truth dataset of Gruber et al., we compare Shaker against a budget-matched ReRun baseline in a paired design, giving both techniques the same number of test executions: Each of 137 tests is run 100 times under each. As configured for Java and Android, Shaker provides no statistically significant detection advantage over plain re-execution (37.2% vs. 35.8%; McNemar exact p = 0.84). Two findings explain why. First, fewer than half of the ground-truth flaky tests reproduce as flaky at all on independent hardware under either technique, and most of the tests that fail to reproduce never diverge once across 100 runs. Second, the tests that do reproduce are dominated by flakiness from network interactions and randomness rather than the concurrency Shaker targets. Beyond the tool, this exposes a broader hazard for the field: reusing a flaky-test ground truth across execution environments silently converts genuine flaky tests into apparent true negatives, deflating any tool's measured recall.
- Abstract（参考訳）: 不安定なテストは、変更のないコードで非決定的にパスまたはフェールし、テストスイートへの信頼を侵食し、すべての失敗のコストを膨らませます。
Shakerは、リソース競合(CPU、メモリ、I/Oストレス)を注入して、同時実行による非決定性を増幅し、JavaとAndroidベンチマークにおける不安定なテストの95%を、平易な再実行(ReRun)のために37.5%と検出したと報告されている。
本稿では,Python 用 Shaker の最初の経験的評価について述べる。
Gruber氏らの基盤構造データセットから、非順序依存のフレキテストを描くことで、ペア設計の予算に適合したReRunベースラインと比較し、両方のテクニックに同じテスト実行数を与えます: それぞれの137テストは、それぞれ100回実行されます。
JavaとAndroid用に設定されているように、Shakerは通常の再実行(37.2%対35.8%; McNemar exact p = 0.84;)に対して統計的に有意な検出の優位性を提供していない。
理由は2つある。
第一に、それぞれの技術の下で独立したハードウェア上では、基幹のフレキなテストの半数以下がフレキで再現され、再生に失敗したテストのほとんどは、100回のランで一度もバラバラになることはない。
第二に、再現するテストは、並行性のShakerターゲットではなく、ネットワークインタラクションとランダム性のフレキネスによって支配される。
実行環境全体にわたってフレキテストの真実を再利用することで、本物のフレキテストが明らかに真の負に変換され、ツールの計測されたリコールが膨らみます。
関連論文リスト
- ExecCritic: Learn to Test, Test to Improve for Coding Agents [68.42713285082912]
実行時のフィードバックは、コーディングエージェントを正しいリポジトリの修復に導くことができますが、テストが問題によって要求された振る舞いをキャプチャした場合のみです。
ExecCriticを導入し、テスト-検証-修正足場と、その中のトレーニングエージェントのためのロール固有の強化学習レシピを組み合わせる。
テストエージェントが独立してリポジトリネイティブなテストを生成し、フェイルクローズされたハーネスがそれらを調整して凍結し、リカバリエージェントがテストを変更することなく、ソースコードを実行フィードバックから修正する。
論文 参考訳（メタデータ） (2026-09-08T17:53:37Z) - How Far Are We from Detecting Flaky Tests? On the Limits of Code-Based Detection [41.369102837712795]
燃えるようなテストは同じコードバージョンでパスしてフェールし、テスト結果のシグナルを弱める。
コードベースのフレキネス検出器は強力なベンチマーク結果を報告しているが、実際の使用は限られている。
フレキネスはテストコードの静的な特性ではなく、テストが不安定かどうかを決定するのに必要な情報が欠けていることが多い、と私たちは主張する。
論文 参考訳（メタデータ） (2026-07-10T12:24:25Z) - Detecting Flaky Tests in Quantum Software: A Dynamic Approach [4.46640294257026]
コードや環境の変更なしに非決定的に通過または失敗する不安定なテストは、ソフトウェアの信頼性に深刻な脅威をもたらす。
本稿では,量子ソフトウェアにおけるフレキテストの大規模動的評価について述べる。
コントロールされた環境で、23リリースにまたがって1万回のQiskit Terraテストスイートを実行しました。
論文 参考訳（メタデータ） (2025-12-19T21:47:31Z) - Systemic Flakiness: An Empirical Analysis of Co-Occurring Flaky Test Failures [6.824747267214373]
不安定なテストは、コードの変更なしに一貫性のない結果をもたらす。
開発者は、毎月2250ドル(約2万5000円)の費用で、不気味なテストの修理に1.28%を費やしている。
フラキーテストは、しばしばクラスタ内に存在し、同じ根本原因を共有する共起失敗は、系統的なフレキネス(systemic flakiness)と呼ばれる。
論文 参考訳（メタデータ） (2025-04-23T14:51:23Z) - 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) - Taming Timeout Flakiness: An Empirical Study of SAP HANA [47.29324864511411]
不安定なテストは回帰テストに悪影響を及ぼします。
テストタイムアウトは、このような不安定なテストの失敗に寄与する要因のひとつです。
テストのフレキネス率は、繰り返しテストの実行回数によって49%から70%の範囲である。
論文 参考訳（メタデータ） (2024-02-07T20:01:41Z) - Do Automatic Test Generation Tools Generate Flaky Tests? [12.813573907094074]
テスト生成ツールが生成するフレキなテストの頻度と性質はほとんど不明である。
EvoSuite(Java)とPynguin(Python)を使ってテストを生成し、各テストは200回実行します。
この結果から, フレキネスは開発者の手書きテストと同様, 生成テストでも一般的であることが判明した。
論文 参考訳（メタデータ） (2023-10-08T16:44:27Z) - FlaPy: Mining Flaky Python Tests at Scale [14.609208863749831]
FlaPyは、研究者がテストスイートを再実行することによって、与えられた、あるいは自動的にサンプルされたPythonプロジェクトの集合で、不安定なテストをマイニングするためのフレームワークである。
FlaPyはコンテナ化と新しい実行環境を使用してテスト実行を分離し、実際のCI条件をシミュレートする。
FlaPyはSLURMを使ってテスト実行の並列化をサポートしており、数千のプロジェクトをスキャンしてテストのフレキネスをスキャンすることができる。
論文 参考訳（メタデータ） (2023-05-08T15:48:57Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。