An Expressive Semantics of Mocking

Svenningsson, Josef; Svensson, H.; Smallbone, Nicholas; Arts, Thomas; Norell, Ulf; Hughes, John

doi:10.1007/978-3-642-54804-8_27

Cited by 8 publications

(9 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…1 Namely, apart from simple checking of operation results for particular values also call-out specifications can be given. These specifications are given in a process algebra-like language [5] and describe the calls to other parts/ operations of the SUT that the operation is allowed or required to make. The tracing of such calls during testing to check against call-out specifications is done by mocking the calls in question following the gray-box testing philosophy, see Sect.…”

Section: Quickcheckmentioning

confidence: 99%

“…In an earlier paper [1], using a small but complete case study from an automotive domain, we have described the method and challenges in model-Email address: wojciech.mostowski@hh.se (Wojciech Mostowski) c 2018, This manuscript version is made available under the CC-BY-NC-ND 4.0 license http://creativecommons.org/licenses/by-nc-nd/4.0/ ing, the mocking mechanism [5], controllable data generators, and, for our project case studies in the automotive domain, the C programming language integration. For the purpose of the presentation, we use a simple coffee machine example.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Model-based fault injection for testing gray-box systems

Mostowski

2019

Journal of Logical and Algebraic Methods in Programming

View full text Add to dashboard Cite

show abstract

Section: Quickcheckmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Model-based fault injection for testing gray-box systems

Mostowski

2019

Journal of Logical and Algebraic Methods in Programming

View full text Add to dashboard Cite

show abstract

“…There was far more to the Volvo project than could be described here. We needed to develop a property-based approach to mocking (Svenningsson, Svensson, Smallbone, Arts, Norell, and Hughes, 2014). We needed to develop ways to cluster models of individual components into an integrated model of a subsystem, because AUTOSAR subsystems are typically implemented monolithically, but specified as a collection of interacting components.…”

Section: In Conclusionmentioning

confidence: 99%

Experiences with QuickCheck: Testing the Hard Stuff and Staying Sane

Hughes

2016

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Abstract. This is not a typical scientific paper. It does not present a new method, with careful experiments to evaluate it, and detailed references to related work. Rather, it recounts some of my experiences over the last 15 years, working with QuickCheck, and its purpose is as much to entertain as to inform. QuickCheck is a random testing tool that Koen Claessen and I invented, which has since become the testing tool of choice in the Haskell community. In 2006 I co-founded Quviq, to develop and market an Erlang version, which we have since applied for a wide variety of customers, encountering many fascinating testing problems as a result. This paper introduces Quviq QuickCheck, and in particular the extensions made for testing stateful code, via a toy example in C. It goes on to describe the largest QuickCheck project to date, which developed acceptance tests for AUTOSAR C code on behalf of Volvo Cars. Finally it explains a race detection method that nailed a notorious bug plaguing Klarna, northern Europe's market leader in invoicing systems for e-commerce. Together, these examples give a reasonable overview of the way QuickCheck has been used in industrial practice.

show abstract

“…An AUTO-SAR module often depends on and makes calls to other AUTOSAR modules. These external modules are mocked [14]; the models include a specification of which (mocked) calls to other modules are to be expected, and what results they should return. In addition to testing a model on its own, it is also possible to combine models together in a cluster.…”

Section: Case Study: Autosar Unit Testsmentioning

confidence: 99%

Linking unit tests and properties

Gerdes

Hughes

Smallbone

et al. 2015

Proceedings of the 14th ACM SIGPLAN Workshop on Erlang

Self Cite

View full text Add to dashboard Cite

QuickCheck allows us to verify software against particular properties. A property can be regarded as an abstraction over many unit tests. QuickCheck uses generated random input data to test such properties. If a counterexample is found, it becomes immediately clear what we have tested. This is not the case when all tests pass, since we do not (and shall not) see the actual generated test cases. How can we be sure about what is tested? QuickCheck has the ability to gather statistics about the test cases, which is insightful. But still it does not tell us whether the particular unit test scenarios we have in mind are included. For this reason, we have developed a tool that can answer this question. It checks if a given unit test can be generated by a property, making it easier to judge the property's quality. We have applied our tool to an industrial use case of testing the AUTOSAR basic software modules and shows that it can handle complex models and large unit tests.

show abstract

An Expressive Semantics of Mocking

Cited by 8 publications

References 5 publications

Model-based fault injection for testing gray-box systems

Model-based fault injection for testing gray-box systems

Experiences with QuickCheck: Testing the Hard Stuff and Staying Sane

Linking unit tests and properties

Contact Info

Product

Resources

About