VLDB 2026 Research / reviewers in the wild / expert
Marcello Cordeiro
dblp:311/8822
· DBLP profile ↗
1ranked-venue papers
1as first author
1since 2021 · last 2021
—ORCID · none
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 testing · 100% |
Topics — the 2 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software testing › flaky test
flaky test detection |
0.5 | 1 | 2021 | Shaker: a Tool for Detecting More Flaky Tests Faster · ASE 2021 |
Software testing
test execution |
0.1 | 1 | 2021 | Shaker: a Tool for Detecting More Flaky Tests Faster · ASE 2021 |
Methods — techniques the papers use, named apart from their topics
stress testing · 0.5noise injection · 0.5
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2021 | Shaker: a Tool for Detecting More Flaky Tests FasterabstractA test case that intermittently passes or fails when performed under the same version of source code and test code is said to be flaky. The presence of flaky tests wastes testing time and effort. The most popular approach in industry to detect flakiness is ReRun. The idea behind ReRun is very simple: failing test cases are re-executed many times looking for inconsistencies in the output. Despite its simplicity, the ReRun strategy is very expensive both in terms of time and in terms of computational resources. This is particularly true for contexts where thousands of test cases are performed on a daily basis. Reducing the rerunning overhead is, thus, of utmost importance. This paper presents SHAKER, an open-source tool for detecting flakiness in time-constrained tests by adding noise in the execution environment. The main idea behind SHAKER is to add stressing tasks that compete with the test execution for the use of resources (CPU or memory). SHAKER is available as a GitHub Actions workflow that can be seamlessly integrated with any GitHub project. Alternatively, SHAKER can also be used via its provided Command Line Interface. In our evaluation, SHAKER was able to discover more flaky tests than ReRun and in a faster way (less re-executions); besides, our approach revealed tens of new flaky tests that went undetected by ReRun even after 50 re-executions. Thanks to its flexibility and ease of use, we believe that SHAKER can be useful for both practitioners and researchers.Demo video: https://youtu.be/7-aiQwOb4rAShaker website: https://star-rg.github.io/shaker Marcello Cordeiro, Denini Silva, Leopoldo Teixeira, Breno Miranda, Marcelo d'Amorim |
ASE | 1 |