Demo Data from EDBT 2026 / reviewers in the wild / expert
Rebecca Hicks
dblp:132/2445
· DBLP profile ↗
1ranked-venue papers
0as first author
0since 2021 · last 2013
—ORCID · unresolved
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1
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 · 56% Requirements engineering and software design · 28% Program analysis · 8% |
Topics — the 4 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design › specification
executable specification |
0.2 | 1 | 2013 | Declarative mocking · ISSTA 2013 |
Software testing › test process › test design
test specification |
0.2 | 1 | 2013 | Declarative mocking · ISSTA 2013 |
Program verification › decision procedure
constraint solver |
0.0 | 1 | 2013 | Declarative mocking · ISSTA 2013 |
Program analysis
constraint solving |
0.0 | 1 | 2013 | Declarative mocking · ISSTA 2013 |
Methods — techniques the papers use, named apart from their topics
executable specification · 0.2constraint solving · 0.2
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2013 | Declarative mockingabstractTest-driven methodologies encourage testing early and often. "Mock objects" support this approach by allowing a component to be tested before all depended-upon components are available. Today mock objects typically reflect little to none of an object's intended functionality, which makes it difficult and error-prone for developers to test rich properties of their code. This paper presents "declarative mocking", which enables the creation of expressive and reliable mock objects with relatively little effort. In our approach, developers write method specifications in a high-level logical language for the API being mocked, and a constraint solver dynamically executes these specifications when the methods are invoked. In addition to mocking functionality, this approach seamlessly allows data and other aspects of the environment to be easily mocked. We have implemented the approach as an extension to an existing tool for executable specifications in Java called PBnJ. We have performed an exploratory study of declarative mocking on several existing Java applications, in order to understand the power of the approach and to categorize its potential benefits and limitations. We also performed an experiment to port the unit tests of several open-source applications from a widely used mocking library to PBnJ. We found that more than half of these unit tests can be enhanced, in terms of the strength of properties and coverage, by exploiting executable specifications, with relatively little additional developer effort. Hesam Samimi, Rebecca Hicks, Ari Fogel, Todd D. Millstein |
ISSTA | 2 |