Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Lucas Zamprogno

dblp:289/1532 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Software testing › test oracle › test oracle generation
assertion generation
0.712023
Dynamic Human-in-the-Loop Assertion Generation · IEEE Trans. Software Eng. 2023
Program analysis
dynamic analysis
0.712023
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
YearPublicationVenuePosition
2023 Dynamic Human-in-the-Loop Assertion Generation
abstract
Test 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 Overreliance
abstract
Autograders 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
SIGCSE2