Step 1: Capture the Conversation
When software components communicate, they use a structured format and conversation, also known as a protocol. Within this structured conversation, observations can be made about static vs. dynamic elements, conversation content and data (the payload), and other aspects of the relationship between the components to create an understanding of the software interaction.
Step 2: Process the Captured Conversation
Here, the Service Virtualization tool evaluates the requirements of the engineering specifications provided or analyzes the captured conversations between components. It is this processing and clever approach to the captured data that is what differentiates using a tool like CA Service Virtualization vs. stubs and mocks.
Step 3: Create a Useable Model
CA Service Virtualization converts these captured conversations and processed protocol request/response pairs into a sophisticated, dynamic model that lives and breathes very similarly to the real thing, and provides the scenario coverage and capabilities for software development and testing activities. The Service Virtualization tool is able to handle difficult tasks such as identifying dynamic data, stateful conversations requiring session IDs and other stateful techniques, and observe real-world variability and dynamic behavior of the conversations. After processing, CA Service Virtualization compiles a conversation into a stateful (or stateless, if desired) model. In this model, we now have the ability to handle challenges like state, automatic dynamic data processing, even populating responses with “fake” suitable test data, automatically solving a huge challenge common for customers around test data management. It is this compilation step that gives the model the rich, dynamic functionality required for realistic virtualization, and makes it not fragile and break-prone as developers use it in new cases and scenarios.
If you want more details on the specifics of how to create virtual services from recordings, R/R pairs, WSDLs and other forms, as well as seeing it all done on video, you can visit the latest CA Service Virtualization documentation site here.
With Service Virtualization, testing teams get access to the dependent systems and services they need to test without having to wait on development or ops. Say someone needs to test a particular service and the service has to be deployed or provisioned by a third party, and only after that happens will you be able to test your part of the code. Well, with Service Virtualization, by using sample request/response pairs, a tester can create, deploy and use the virtual service and no longer be dependent on any third party, saving time and money.
For example, CA Service Virtualization automatically detects dynamic date behavior and can model dates to be scenario accurate, regardless of the actual date of the transaction or virtualized response. This creates models that work well into the future, unlike static stubbing and mocking, which is either fragile or very expensive to create and maintain.