Service Virtualization

Hi all,

I'm trying to virtualize a REST service. In my request, one of the elements is repetitive, i.e. it can occur one or more times. The same element is also repetitive in the response too.

So, if the request has three nodes of that element, the response also has the same three nodes of that element with values also same in it.

How do i virtualize this dynamic behavior. I don't want to record the VSI with some static request-responses which has two or three nodes, but i want to be dynamic as mentioned above.

I know that I have to write java code and check the incoming request and prepare the outgoing response accordingly. But don't know how to implement it.

Please suggest.

My question is exactly same as this another question that was asked long back but is unanswered:

Virtualization of a GET serevice with dynamic response

I ended up having to write my own matcher to handle varying sized arrays and structures.  the fixed pattern matching in DT just made it too hard, specially with the dev team was changing the new api every day.

the org.skyscreamer.jsonassert library made the match failures easy to decode and the  com.github.fge.jsonschema schema checking allowed us to feel confident the messages were in the right format before comparing to the specific message sample

because we have so many different message formats coming in over the same url family in the same service, . we could not use the DT JSON Schema filter checking support (as we couldn't parameterize it)

and the output message format doesn't match the input message format.

we can also compare on headers (metadata) which DT does not.

while I agree with Rick that you need to keep the subset of the testcases down, in our case we have no control over the message submitters, and want to make as much work correctly as possible.

by using schema checking, and some wildcard notation in the compare (*variablename instead of exact structure or array content) we were able to allow any kind of content match (with and without case sensistivity)

AND be able to copy the input content (regardless of size or structure) to the  output.

DT only support single fields, not structures or arrays as magic string.

As you said, you can code it, or you could script it in a Scriptable Data Protocol Handler, or even investigate whether the facilities in "Data Driven Virtual Services" (introduced in DevTest v8.5) is most appropriate for you (and include "Request Data Manager" DPH to "keep" the arguments you will always match against, discarding/moving any repeating elements if you will be creating response blocks in a DPH). However, what different use cases are you enabling by doing so?

I think the industry figure is that 70% of tests should be negative testing, so by creating dynamic data responses simply for repeating success conditions, all you're doing is streamlining a bit of the remaining 30%.

What I mean is ... DevTest permits any responses, any business logic differences, any delays, any timeouts, any logic errors that you might want to test for. If there are boundary conditions (in your example, there might be a difference if you have 0 repeating blocks, 1 repeating block, 10 repeating blocks, 256 repeating blocks, etc), it is interesting to have these conditions in your response rather than focusing on dynamic responses that don't increase test coverage. So, in this case you would have 4 static responses, which can be created in seconds and enable your boundary testing conditions and so eating into the 70% of negative testing you should be doing, rather than spending any time on creating something dynamic that won't actually add much value.

If you want to create dynamic responses because your QA efforts are being measured on "number of tests executed", and you can successfully run thousands of automated regression tests if you have dynamic responses, testing the same logic in the application each time and improving the perceived value of QA, then there's an organisational problem rather than a technical one.