- Author: [[infoq.com]] - Full Title: Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams - Tags:: [[articles]] - URL: https://www.infoq.com/articles/stubbing-mocking-service-virtualization-differences/ - Zettels:: <!--ID: 1631100134055--> - [[Test doubles]] - [[Stubs]] - [[Mocks]] - [[Service virtualization]] - ### Highlights first synced by [[Readwise]] [[2020-09-06]] - Service virtualization is a technique for decoupling a test suite from environmental dependencies that is growing in popularity. It is part of the broader category of "test doubles" that include mocks and stubs. - A test double is an object that stands in for a real object in a test. A test double allows us to decouple the application from the dependencies when testing the system under test (SUT). You replace the dependency with an equivalent interface that allows you to exercise a given test case. - Common categories of a test double used for testing and quality assurance: stub (a servlet in a WAR file created using SoapUI and deployed to a remote Jetty instance at http://testEnv.mycompany.com/getWeatherService) virtual service (an artifact created with a service virtualization tool and deployed to a remote shared virtual service environment at http://vsenv.mycompany.com:9034/getWeatherService) - Stub: a minimal implementation of an interface that normally returns hardcoded data that is tightly coupled to the test suite. It is most useful when the suite of tests is simple and keeping the hardcoded data in the stub is not an issue. - `Mock: a programmable interface observer, that verifies outputs against expectations defined by the test. It is frequently created using a third party library, for example in Java that is Mockito, JMock or WireMock. It is most useful when you have a large suite of tests and a stub will not be sufficient because each test needs a different data set up and maintaining them in a stub would be costly. The mock lets us keep the data set-up in the test. ` - Mock provides responses based on a given request satisfying predefined criteria (also called request or parameter matching). A mock also focuses on interactions rather than state so mocks are usually stateful. For example, you can verify how many times a given method was called or the order of calls made to a given object. - Virtual service: a test double often provided as a Software-as-a-Service (SaaS), is always called remotely, and is never working in-process directly with methods or functions. A virtual service is often created by recording traffic using one of the service virtualization platforms instead of building the interaction pattern from scratch based on interface or API documentation. A virtual service can be used to establish a common ground for teams to communicate and facilitate artifact sharing with other development teams as well as testing teams. A virtual service is called remotely (over HTTP, TCP, etc.) normally supports multiple protocols (e.g. HTTP, MQ, TCP, etc.), while a stub or mock normally supports only one. - `Service virtualization tools used to create virtual services will most often have user interfaces that allow less tech-savvy software testers to hit the ground running, before diving into the details of how specific protocols work. ` - What is service virtualization? It is the practice of creating virtual services and sharing them between developers and testers within a team and across teams. - Use stubs when the test data needed is not complex. If the test data is complex, use mocks instead, so that all the setup is performed in the tests. > Here are two example situations where a stub is likely to be a good approach: - If you are a backend developer working on a small new application that uses a third party library to communicate with an external API, you can create an interface in your code to decouple yourself from that third party library. For unit tests, write a stub that returns hard coded values. For end to end testing, implement the interface using the third party library classes. - If you are a tester who needs to test an application in isolation from the dependencies, create a stub for the HTTP RESTful APIs that the application depends on. Use in house tools provided by your team’s developers. ^8a52b8 > Now two examples situations where a mock is likely a good choice: - If you are a back end developer working on a fairly large application and you need to decouple from any HTTP API dependencies, use a remote mocking framework such as WireMock or mountebank and prime the mocks in the acceptance tests. - If you are a back end developer working with a code base that has thousands of class unit tests then Mockito could allow you to mock the dependency classes in any tests. > Finally, [some] examples where a virtual service should be considered first: - If you are a developer working on a very large and complex legacy application that has many dependencies and your current test coverage is very low (e.g. less than 5%)--especially if the system dependencies are unavailable more than two-thirds of the time. A service virtualization tool would allow you to record traffic when the dependencies are available, so that later, you can test using virtual services by replaying the traffic. This limits the impact of downtime of the dependencies for both you and your testers when you let them make use of the virtual services. This is a short term or tactical approach to give you time to create a suite of automated tests for your application that would not use recorded but primed data. How well this can be implemented depends on the nature of the system you are working with. It can be very easy or close to impossible to deliver depending on the details. - If you are a front end developer working with a public SOAP (Simple Object Access Protocol) like Weather API, take advantage of Sandbox (getsandbox.com) or TrafficParrot (trafficparrot.com) to generate the virtual service using a WSDL file. Set up the test data in the virtual service so that all of your test cases are represented. For example, temperatures below ­-60°C (which are never returned from the real Weather API). - If you are an NFT (Non-Functional Testing) tester responsible for the performance of a large banking application, use tcpdump to record incoming and outgoing traffic in a production environment for a day. Next import the outgoing traffic using a service virtualization tool and create a virtual service. You can import the incoming traffic to JMeter using tcpreplay and JMeter Proxy. Run a test suite in your performance environment using JMeter and use the virtual services to decouple yourself from other dependencies. Just to be safe, repeat the recording process every week. This could prove to be very easy or very difficult to implement depending on the specifics of the system you are working with. > Resources for digging deeper A good overview of stubs and mocks can be found in the GooS book http://www.growing-object-oriented-software.com/. If you are a software developer, try using Mockito to learn how to do mocking. If you are a software tester try doing stubbing using any of the open source tools. A list of the tools can be found here: http://blog.trafficparrot.com/2015/05/service-virtualization-and-stubbing.html It's also worth reviewing any of the enterprise vendors like CA, IBM or Parasoft but as ThoughtWorks observed in Jun 2014 most of the innovation comes from practitioners contributing to open source.