Service Virtualization

Hi All,

I would like to clarify few things related to stateful service implementation in CA DevTest. I have one scenarios as below. Will it be possible to achieve it without any custom scripting. Most of the other tools like mockito or wiremock has capability to implement this scenario and get the output as expected as mentioned below consecutive calls.

Call 1 : GET /sqlrest/customers/               : Client will get a 1 customer record

Call 2 : POST /sqlrest/customers/add

Call 3 : GET /sqlrest/customers/               : Client will get a 2 customer records

Call 4 : POST /sqlrest/customers/add

Call 5 : GET /sqlrest/customers/               : Client will get a 3 customer records

Please suggest. Thanks.

Manage state through customer number.

Thanks Vasmi. But here we dont have any customer id to maintain session. As I will go on adding new customers, i will always get a list of all customers. I have only 2 transactions ADD and GET customer.

What are you testing in this scenario?

• If it's that customers get added, then you specifically do NOT want to use service virtualisation or even stubbing - the front-end is simply validating the back-end, and the back-end is what's being tested.
• If it's that a newly-added customer is shown, then you specifically do NOT want to use service virtualisation or stubbing, as you are actually validating that back-end data storage & retrieval works as expected.
• If it's that different numbers of customers can be checked, this is a candidate for interesting responses, so check the "allow duplicate specific transactions" box and record multiple interactions. You will see that you have multiple different responses to your GET, and DevTest will round-robin each response, allowing you to check for correctness without having to even make the addCustomer call. It's trivial to add extra responses to the list, supporting any number of customers to be returned, or error messages, timeouts, boundary conditions, anything that your testers can imagine being problems, and therefore the QA process finds more defects earlier in the testing process.