Demo Data from EDBT 2026 / reviewers in the wild / expert
Lucas Zamprogno
dblp:289/1532
· DBLP profile ↗
2ranked-venue papers
1as first author
2since 2021 · last 2023
0000-0003-4489-5347ORCID · corroborated
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 2021Human-computer interaction and ubiquitous computing · 1 · 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 · 67% Program analysis · 33% |
Topics — the 2 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software testing › test oracle › test oracle generation
assertion generation |
0.7 | 1 | 2023 | Dynamic Human-in-the-Loop Assertion Generation · IEEE Trans. Software Eng. 2023 |
Program analysis
dynamic analysis |
0.7 | 1 | 2023 | Dynamic Human-in-the-Loop Assertion Generation · IEEE Trans. Software Eng. 2023 |
Methods — techniques the papers use, named apart from their topics
dynamic analysis · 0.7
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2023 | Dynamic Human-in-the-Loop Assertion GenerationabstractTest cases use assertions to check program behaviour. While these assertions may not be complex, they are themselves code that must be written correctly in order to determine whether a test case should pass or fail. We claim that most test assertions are relatively repetitive and straight-forward, making their construction well suited to automation and that this automation can reduce developer effort while improving assertion quality. Examining 33,873 assertions from 105 projects revealed that developer-written assertions fall into twelve high-level categories, confirming that the vast majority ($>$90%) of test assertions are fairly simple in practice. We created AutoAssert, a human-in-the-loop tool to fit naturally into a developer's test-writing workflow by automatically generating assertions for JavaScript and TypeScript test cases. A developer invokes AutoAssert by identifying the variable they want validated; AutoAssert uses dynamic analysis to generate assertions relevant for this variable and its runtime values, injecting the assertions into the test case for the developer to accept, modify, delete. Comparing AutoAssert's assertions to those written by developers, we found that the assertions generated by AutoAssert are the same kind of assertion as was written by developers 84% of the time in a sample of over 1,000 assertions. Additionally we validated the utility of AutoAssert-generated assertions with 17 developers who found the majority of generated assertions to be useful and expressed considerable interest in using such a tool for their own projects. Lucas Zamprogno, Braxton Hall, Reid Holmes, Joanne M. Atlee |
IEEE Trans. Software Eng. | 1 |
| 2021 | STOP THE (AUTOGRADER) INSANITY: Regression Penalties to Deter Autograder OverrelianceabstractAutograders are an invaluable tool for deploying assessments in large classes. However students sometimes rely on the autograder in place of careful thought for ways to improve to their solution. We sought to naturally encourage students to check their own solutions more, and hammer the grader less. To do this, we imposed a penalty each time a student's grade went down: we called these regression penalties. We assessed whether the introduction of these penalties resulted in less reliance on the autograder without hurting student performance. Elisa L. A. Baniassad, Lucas Zamprogno, Braxton Hall, Reid Holmes |
SIGCSE | 2 |