An Expressive Semantics of Mocking
We present a semantics of mocking, based on a process calculus-like formalism, and an associated mocking framework. We can build expressive mocking specifications from a small, orthogonal set of operators. Our framework detects and rejects ambiguous speci
- PDF / 228,152 Bytes
- 15 Pages / 439.363 x 666.131 pts Page_size
- 11 Downloads / 204 Views
Chalmers University of Technology, Gothenburg, Sweden 2 Quviq, Gothenburg, Sweden
Abstract. We present a semantics of mocking, based on a process calculus-like formalism, and an associated mocking framework. We can build expressive mocking specifications from a small, orthogonal set of operators. Our framework detects and rejects ambiguous specifications as a validation measure. We report our experience testing software components for the car industry, which needed the full power of our framework.
1
Introduction
Software components rarely exist in isolation; most components not only provide an API, but depend on the APIs of other components. When a component is tested in isolation, then these other APIs must be replaced by a suitable simulation. Nowadays “mocks” are often used for this purpose, which not only simulate the other components, but also help to check that they are used correctly. There are many mocking frameworks available to support mocking, such as Google Mock [9] for C++, or jMock [11] or Mockito [12] for Java. Yet we developed a new framework of our own—why? We recently designed conformance tests for parts of the AUTOSAR automotive software standard [3]. The goal was to test different vendors’ implementations of AUTOSAR components for compliance with the standard. We needed mocks in order to test each component in isolation. We had three main requirements which ruled out existing mocking frameworks. Expressive. AUTOSAR does not completely specify how a compliant component must behave, and different vendors interpret the standard differently. Therefore, the system under test might invoke the mocks in a variety of very different ways. As we cannot tailor our tests to the vendor’s implementation, our mocks must handle this diversity instead. To allow diverse behaviour without making the mocks too permissive, we need an expressive mocking framework. Orthogonal. Many mocking frameworks have a non-orthogonal feature set. For example, mocking frameworks support optional calls, which the system under test may call or ignore, but it is often not possible to mark a sequence of calls as optional, so that either the whole sequence must be called or none at all. In the AUTOSAR project we used QuickCheck [6,2] to model the software components. From the model we can generate test cases and corresponding S. Gnesi and A. Rensink (Eds.): FASE 2014, LNCS 8411, pp. 385–399, 2014. c Springer-Verlag Berlin Heidelberg 2014
386
J. Svenningsson et al.
mocks; generating the mocks is extremely painful if the mocking framework imposes arbitrary restrictions on what we can write. We want the freedom to combine the features of the mocking framework however we like. Clear and unambiguous specifications. In most mocking frameworks, the meaning of a specification can be quite subtle, a point we illustrate in Section 2. For example, these frameworks have rules for resolving ambiguity, and the user can exploit these rules in writing specifications. This is convenient but makes it hard to say what a given specification means. Our A
Data Loading...
