Demo Data from EDBT 2026 / reviewers in the wild / expert
Cong Pan 0002
dblp:151/5049-2
· DBLP profile ↗
1ranked-venue papers
1as first author
1since 2021 · last 2021
0000-0002-4955-7761ORCID · verified
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 first-author · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Software maintenance and evolution · 77% Empirical software engineering · 23% |
Topics — the 2 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software maintenance and evolution › release engineering
continuous integration |
0.5 | 1 | 2021 | Continuous test suite failure prediction · ISSTA 2021 |
Empirical software engineering › mining software repositories › defect prediction
just-in-time defect prediction |
0.1 | 1 | 2021 | Continuous test suite failure prediction · ISSTA 2021 |
Methods — techniques the papers use, named apart from their topics
machine learning · 0.5cost model · 0.5
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2021 | Continuous test suite failure predictionabstractContinuous integration advocates to run the test suite of a project frequently, e.g., for every code change committed to a shared repository. This process imposes a high computational cost and sometimes also a high human cost, e.g., when developers must wait for the test suite to pass before a change appears in the main branch of the shared repository. However, only 4% of all test suite invocations turn a previously passing test suite into a failing test suite. The question arises whether running the test suite for each code change is really necessary. This paper presents continuous test suite failure prediction, which reduces the cost of continuous integration by predicting whether a particular code change should trigger the test suite at all. The core of the approach is a machine learning model based on features of the code change, the test suite, and the development history. We also present a theoretical cost model that describes when continuous test suite failure prediction is worthwhile. Evaluating the idea with 15k test suite runs from 242 open-source projects shows that the approach is effective at predicting whether running the test suite is likely to reveal a test failure. Moreover, we find that our approach improves the AUC over baselines that use features proposed for just-in-time defect prediction and test case failure prediction by 13.9% and 2.9%, respectively. Overall, continuous test suite failure prediction can significantly reduce the cost of continuous integration. Cong Pan 0002, Michael Pradel |
ISSTA | 1 |