Service Virtualization
What is Service Virtualization and how can you benefit from it by using Service Virtualization tools like Ekko Poxy. We'll seek to answer those questions in the following sections.
What is Service Virtualization?
Service Virtualization, also sometimes referred to as API simulation, emulates or simulates the behaviors of services / APIs that are otherwise unavailable or difficult to access while testing.
With today's increasingly complex applications, which often consists of many interdependent components and systems, it's getting harder for software development teams to deliver high-quality products to market on schedule, on budget, and without errors.
Adding to these complexities are organizations transformation to agile operating models / methodology with more iterations and compressed development timescales. By leveraging service virtualization, organizations can achieve more in each iteration within the reduced time frame because they have the support of virtualized services / environments to remove the agile bottlenecks incurred when dependent APIs are unavailable or difficult to access. There can be many reasons why resources might be unavailable or difficult to access: components may still be under development, undergoing maintenance / deployment, strenuous to set up, owned by third parties, costly to call or restricted in some other way. By utilizing virtualization developers and testers are no longer dependent on these components or immediately blocked by the teams delivering these dependent assets and can continuously perform integration testing at virtually any point of the development lifecycle or early on in sprints.
As an example consider a scenario where an credit card company is developing a new mobile app for customers to apply for a new range of cards they are launching. To do this they need to make use of a third-party credit check / scoring service however the vendor does not currently provide a test version of the service. Without service virtualization the development team would have to make some tough choices on how to do the necessary testing - none of which are good options.
Instead a setup as depicted below would provide a multitude of benefits for any software development team:
Ekko Proxy Service Virtualization
In conclusion, the use of simulation technologies such as Ekko Poxy overcomes the constraints associated with the dependent systems outside of your control enabling you to run meaningful end-to-end tests in the development phases. Service virtualization shifts the ability to test applications earlier in the development lifecycle, thus enabling integration and release processes to happen faster, with both greater quality and less risk. In addition, it enables other non-functional testing, such as performance and load testing against a simulated environment.
Why use Service Virtualization?
Traditionally, especially in waterfall development, testing teams have had to wait for close to completed applications to be deployed before proper functional, integration, and performance testing would be able to begin. Different teams may even produce separate artifacts of an application or system, piece by piece, and then assemble them at the end into a working product before testers are able to put it through the testing cycles. This process, whilst logical, is sequential and pretty slow going.
While testing a finished or nearly finished application - fully integrated with all it's dependent services etc. - is still an important task it's far from ideal or not even practical having to wait that long before being able start significant testing. This is why more and more, if not most, organizations have adopted an Agile methodology of continuous integration and continuous delivery (CI/CD) allowing the release of value and benefits early on. With CI/CD it's not pragmatic or even possible to wait long before testing to see how various software components communicate with each other. Hence testing needs to happen alongside development right from the start, and this is especially true for modern applications consisting of multiple layers of interdependent components e.g. microservices, third-party apps, and APIs.
With service virtualization in the picture, the integration of application components can take place early on in the development cycle thereby reducing time and cost to fix bugs - before they become significant issues.
It's often a misconception that service virtualization is a huge enterprise to setup and that it takes a significant investment in time and capital to get started and as a consequence is reserved for big organizations only. For some service virtualization solutions out there that may be the case, however for Ekko Poxy this is not the case and you can literally be up and running in minutes. Whether you have existing services that you want to record and playback or want to create new virtualized services that will allow you to take advantage of all the benefits of service virtualization - Ekko Poxy can help you achieve that.
Benefits of Service Virtualization
The figure depicted below shows some of the main benefits and features of Service Virtualization:
Key Service Virtualization benefits explained:
Further, research by Gartner, which analyzed a survey of 500-plus companies, found that service virtualization led to the following efficiencies:
This research validates what analysts have found from studying various organizations implementations of service virtualization and the results of those implementations over the years. They have continually found that organizations using service virtualization experience reduced costs, reduced time to market, and increased software quality.
Mocking / Stubbing vs Service Virtualization
Service virtualization is often confused with stubbing or mocking as they aim to achieve similar goals. Whilst they look to fulfil much the same goals there are big differences however in the way you work and interact with them. Stubs and Mocks (themselves slightly different) are fake software components that are generally employed to 'skip' unavailable system components, which are very specialised to a particular test or set of tests, and require manual coding with a fair bit of effort to implement. In contrast, service virtualization tools like Ekko Poxy can provide a simulated environment or a specific set of simulated services of a system that can be accessible to the entire team with minimal effort to setup.
Another important distinction is that with mocking, individual classes can be simulated, or with stubbing, classes can be given predetermined behavior, while service virtualization can simulate the behavior of entire networked backend services. From an application perspective, the responses issued by virtualized services are as good as the real thing.
Stubs
A stub is a barebone implementation of an interface that generally 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. Most stubs are handwritten though some can be generated by tools. Stubs are normally written by developers for their own use though they can be shared with testers, but wider sharing is typically limited by interoperability issues related to software platform and deployment infrastructure dependencies that were hardcoded. Conventionally a stub works in-process directly with classes, methods, and functions for unit, module, and acceptance testing. Unlike mocking, you cannot verify an invocation on a stub. Stubs can also be written to communicate over a network like HTTP in which case some may argue that they should be called virtual services but they are not virtualized services in the true sense of the word.
Mocks
A mock is a programmable interface observer, that verifies outputs against expectations defined by the test. They are frequently created using a third party library, for example in Java that is Mockito, JMock and or WireMock. They are most useful when you have a large suite of tests where stubs will not be sufficient because each test needs a different data set up and maintaining them in a stub would be awkward and costly. Mocks lets you keep the data set-up in the test and are generally written by developers for personal use as part of unit tests but they can be shared with testers. However, as with stubs, wider sharing is typically limited by interoperability issues related to software platform and deployment infrastructure dependencies that were hardcoded. They most often work in-process directly with classes, methods, and functions for unit, module, and acceptance testing. Mocks provide responses based on a given request satisfying predefined criteria. 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.