Modeling with Mocking

Stoel, Jouke; Storm, Tijs van der; Vinju, Jurgen

doi:10.1109/icst49551.2021.00018

Cited by 4 publications

(2 citation statements)

References 30 publications

(39 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Mockingbird by Lockwood et al [38] uses mocks to isolate the code under dynamic analysis from its dependencies. The use of mocks for Test Driven Development [39], modeling [40], and as an educational tool for object-oriented design [41], [42] have also been investigated. These works have been inspirational for us in many respects.…”

Section: Studies On Mockingmentioning

confidence: 99%

Mimicking Production Behavior with Generated Mocks

Tiwari¹,

Monperrus²,

Baudry³

2022

Preprint

View full text Add to dashboard Cite

Mocking in the context of automated software tests allows testing program units in isolation. Designing realistic interactions between a unit and its environment, and understanding the expected impact of these interactions on the behavior of the unit, are two key challenges that software testers face when developing tests with mocks. In this paper, we propose to monitor an application in production to generate tests that mimic realistic execution scenarios through mocks. Our approach operates in three phases. First, we instrument a set of target methods for which we want to generate tests, as well as the methods that they invoke, which we refer to mockable method calls. Second, in production, we collect data about the context in which target methods are invoked, as well as the parameters and the returned value for each mockable method call. Third, offline, we analyze the production data to generate test cases with realistic inputs and mock interactions. The approach is automated and implemented in an open-source tool called RICK. We evaluate our approach with three real-world, open-source Java applications. RICK monitors the invocation of 128 methods in production across the three applications and captures their behavior. Next, RICK analyzes the production observations in order to generate test cases that include rich initial states and test inputs, mocks and stubs that recreate actual interactions between the method and its environment, as well as mock-based oracles. All the test cases are executable, and 52.4% of them successfully mimic the complete execution context of the target methods observed in production. We interview 5 developers from the industry who confirm the relevance of using production observations to design mocks and stubs.

show abstract

Section: Studies On Mockingmentioning

confidence: 99%

Mimicking Production Behavior with Generated Mocks

Tiwari¹,

Monperrus²,

Baudry³

2022

Preprint

View full text Add to dashboard Cite

show abstract

“…Since an abort vote directly finishes the transaction for that resource, it no longer has to consider this operation when handling other incoming operations. For some more domain specific use cases, such as Rebel [26,27] for SIE, specialized static analyses based on some grouping of return values can be useful, but it is not generalizable.…”

Section: Ie and Rv-ser Another Conflict Relation Compatible Withmentioning

confidence: 99%

Contract-based return-value commutativity: safely exploiting contract-based commutativity for faster serializable transactions

Soethout

Storm

Vinju

2021

Proceedings of the 11th ACM SIGPLAN International Workshop on Programming Based on Actors, Agents, and Decentralized Control

View full text Add to dashboard Cite

A key challenge of designing distributed software systems is maintaining data consistency. We can define data consistency and data isolation guarantees -e.g. serializability-in terms of schedules of atomic reads and writes, but this excludes schedules that would be semantically consistent. Others use manually provided information on "non-conflicting operations" to define guarantees that work for more applications allowing more parallel schedules. To be safe, an engineer might avoid marking operations as non-conflicting, with detrimental effects to efficiency. To be fast, they might mark more non-conflicting operations than is strictly safe.Our goal is to help engineers by automatically deriving commutative operations (using their respective contracts) such that more parallel schedules with global consistency are possible. We define a new general consistency and isolation guarantee named "Return-Value Serializability" to check consistency claims automatically, and we present distributed event processing algorithms that make use of the same "Contractbased Commutativity" information. We validated both the definitions and the algorithms using model-checking with tla + . Previous work provided evidence that local coordination avoidance such as applied here has a significant positive effect on the performance of distributed transaction systems.Client-centric return-value commutativity promises to hit a sweet spot in design trade-offs for business applications, such as payment systems, that must scale-out while their operations are not embarrassingly parallel and consistency guarantees are of the highest priority. It can also provide design feedback, indicating that some operations will simply not scale together even before a line of code has been written.

show abstract