I work at a place whose software interacts with web services run by other companies. Sometimes the test environments of those external web services stop, so using autoresponses to simulate external dependencies is a big deal for us. I've recently been using AutoResponder/FiddlerScript to simulate external dependencies by responding with traffic saved to disk whenever the URL and/or headers match some condition, and it's worked very well.
However, AutoResponder has one drawback: the responses from disk are sent unmodified, and sometimes I would like to change things based on the content of the request.
As a minimal example, suppose I save to disk a request/response pair like this:
POST https://somewebsite.com/CreateThing HTTP/1.1
{"Name":"Honeoye Falls"}
HTTP/1.1 200 OK
{"Name":"Honeoye Falls", "Successfully POSTed": "True"}
I'd like AutoResponder or FiddlerScript to be able to respond to the following request:
POST https://somewebsite.com/CreateThing HTTP/1.1
{"Name":"Bancorp Tower"}
with the following response:
HTTP/1.1 200 OK
{"Name":"Bancorp Tower", "Successfully POSTed": "True"}
I have a naive fantasy of building an "AutoResponder Plus" tab into Fiddler where you can drag a session in and tag parts of the request body as "magic fields" to build an "enhanced rule". In this example, the "Name" field would be a "magic field", because it occurs identically in both request and response. AutoResponder would then respond to requests matching the rule by loading the original response from disk (say, the one with "Name": "Honeoye Falls"), but overwriting "magic" fields in the response with the ones from the request (giving "Name": "Bancorp Tower").
In this minimal example, I know how to manually write FiddlerScript that would perform the substitution, but for more complicated examples with dozens of magic fields, writing FiddlerScript code for each quickly becomes time-consuming and mind-numbing. Automating the identification of "magic fields" in request/response pairs when they get drag-and-dropped into AutoResponder would be awesome, as would the ability to "intelligently" respond to requests containing them.
Here's my actual question:
- How naive a fantasy is this? How difficult might it be for me to build such a Fiddler add-on? Is this even feasible, or worthwhile?
Other software with this capability currently exists, but is cumbersome; I'm exploring CA Service Virtualization, which is a heavyweight, complicated software suite that seems overkill, but will probably work. As a side hobby, I'm interested in making this possible in Fiddler. But again, I don't know whether this would be worthwhile or easy.
What's your opinion?
1 Answer, 1 is accepted
The short answer is that it's "possible" (to some extent) but it's unlikely to be *easy*.
Similar functionality is envisioned for Fiddler's APITest tab (see http://www.telerik.com/blogs/api-testing-with-telerik-fiddler).
In Telerik's TestStudio web testing product, we call this feature "Dynamic Targets." The code tries to identify a "Source" and a "Target" such that the value from one seamlessly flows from one to the other as the test executes.
In practice, this is very difficult, because there are so many different standard (and non-standard) ways of passing values around-- query strings, headers, and body can all serve as either a source or a destination, and there are tons of encodings (plaintext, urlencoding, base64, XML, JSON, etc, etc). Mapping one to another (especially automatically) is quite difficult.
A typical approach is to run a set of rules one each response ("Extraction rules") and on each subsequent requests ("Replacement rules"); those rules could be manually created by the user and there could be templates for the most common types of replacements. But this is all quite a bit of code, and it's not clear how well it will scale to the breadth of real-world applications out there.
The present approach I'm considering is something a bit simpler; you markup a "template" response with tags, e.g. {{username}} and that template gets filled based on a "state bag" which in turn gets filled by prior responses, where a developer-written regular expression defines the value, e.g.
username=.*userloginname=([^;]+).*
Regards,
Eric Lawrence
Telerik