Stubs, mocks or virtual assets?

If, during the software development process, you stumble upon the need to access software components that:

  • Have not yet been developed,
  • Do not contain sufficient test data,
  • Require access fees, or
  • Are otherwise constrained with regards to accessibility,

there are several options you may consider to work around this issue. In this post, I will introduce three options and explain some of the most important of their characteristics.

Please note that the terms ‘stub’ and ‘mock’ are often mixed up in practice, so what is defined as a mock here might be called a stub somewhere else and vice versa. However, I tried to use definitions that are more or less agreed upon in the development and testing community.

The simplest form of removing dependency constraints is the use of stubs. A stub is a very simple placeholder that does pretty much nothing besides replacing another component. It provides no intelligence, no data driven functionality and no validations. It can be created quickly and is most commonly used by developers to mimick behaviour of objects and components not available in their development environment.

Mocks contain a little more intelligence compared to stubs. They are commonly configured to be used for specific test or development purposes. They are used to define and verify expectations with regards to behaviour. For example, a mock service might be configured to always return certain test data in response to a request recevied, so that specific test cases can be executed by testers. The difference between mocks and stubs from a testing perspective can be summarized by the fact that a mock can cause a test case to fail, whereas a stub can’t.

Virtual assets
Virtual assets are simulated components that closely mimic the behaviour of ‘the real thing’. They can take a wide variety of inputs and return responses that their real-life counterpart would return too. They come with data driven capabilities that allow responses (and therefore behaviour) to be configured on the fly, even by people without programming knowledge. Virtual assets should also replicate connectivity to the simulated component by applying the same protocols (JMS, HTTP, etc.) and security configuration (certificates, etc.). The application of virtual assets in test environments is commonly called service virtualization.

Testing terms related to stubs and mocks

If you want to read more about component or API stubbing, mocking or virtualization, this page in the SmartBear API Testing Dojo provides an interesting read. Also, Martin Fowler wrote a great piece on mocks and stubs on his blog back in 2007.

10 thoughts on “Stubs, mocks or virtual assets?

        • If you’re working on a distributed application that requires a component (for example an external web service) to function, but that external web service is not available for some reason, you’ll need something that simulates the behavior of that service for development and testing purposes. You can simply stub or mock it, or choose to create a virtual service using a service virtualization solution. The choice depends on your testing and development requirements.

  1. Hi Bas,
    If i have more than one class to run(all at once),can i do it with ExtentReport?Or i have to do it with TestNG and testng.xml?

    • You can do that with ExtentReports without any trouble I think. Check the 2.0 release for the ability to run tests in parallel and generate reports for them.

      Oh, and please make sure to post your questions as a comment to the relevant post, that keeps things readable for everyone.

  2. Pingback: Testing Bits – 7/26/15 – 8/1/15 | Testing Curator Blog

  3. Hi Bas,
    I think i made a mistake.sorry for asking stupid things.maybe i could have emailed the above said things.As you know i am only a beginner in many things including asking foolish things to people openly.i know how hard it is to makes blog like yours.if i have tried to put a bad feel to it accidentally forgive me ok?

Leave a Reply

Your email address will not be published. Required fields are marked *