Is it possible to use the command line to replay SAZ files with Fiddler? While I understand that you can specify a SAZ file to open with Fiddler from the command line, I am looking for something that will perform the following steps:
* Replay the SAZ file
* Exit with a reasonable return code
If this process could be run headless, that'd be even better. While this doesn't seem too much to ask, I haven't had much luck figuring it out myself. This will be part of a larger, automated process.
If I'm barking up the wrong tree, what is the recommended way to replay SAZ files in an automated fashion?
8 Answers, 1 is accepted
I actually have a post-it note on my desk with the title "Fiddler Replayer" that describes the scenario you're asking about.
Today, you could emulate this with FiddlerScript or an extension, but the best way to do it is to build an application on top of FiddlerCore which would also meet your "headless" goal.
I'm very curious to know what features you'd want in a replayer-- for instance, is your goal to capture the responses (into a new SAZ) or do you only want to send the requests? How should the "reasonable return code" be determined?
Regards,
Eric Lawrence
Telerik
Rank 1
Hi Eric,
Thanks for the quick response. My use-case for a Fiddler Replayer would be to replay captured network traffic generated from desktop application, allowing me to "spoof" the actions performed by that application in an automated testing environment. This is important as said desktop application contains no internal hooks which I could call in an automated fashion.
To that end, all I would require in a Fiddler Replayer is a tool that can replay a specified SAZ file and then terminate when finished. Capturing the entirety of the response data isn't necessary.
What I meant by a "reasonable return code" is highly negotiable and would basically any return code. Starting Fiddler from the command line, specifying a SAZ, merely opens the Fiddler GUI and never returns anything. An automated system has no idea when and if the Fiddler process actually did anything. In this case, "reasonable return codes" could be something like "hi, I finished", "that saz was invalid", "uh oh, I got a 401/403 as part of the response", "oops, I got a 500 as part of the response". An entire captured response SAZ may be unreasonably cumbersome to parse. Any return code that tells me Fiddler has finished working and whether it did what I was expecting would count as "reasonable" to me.
Today the way to go is definitely using FiddlerCore (the app would be a few dozen lines of code). I'm investigating what I might to add to Fiddler to address this scenario.
Regards,
Eric Lawrence
Telerik
Rank 1
Thanks, Eric, for the quick response. While it is a little disappointing that this functionality is not already baked in, your answer puts me on a clear trajectory for how to fulfill my requirements. I believe someone else at my company was playing with writing Fiddler extensions so they may be able to help me with a FiddlerCore solution.
I suppose I'll have to key my eye on any changelogs for any possible new command line functionality.
Cheers!
Regards,
Eric Lawrence
Telerik
Rank 1
Hello,
I am trying to find a way to use the command line to replay SAZ files with Fiddler as well and am glad to find this post.
Being very new to Fiddler, I am looking for some help writing the app using FiddlerCore as suggested. In particular, after I load the saz file, I get an array of sessions. How do I then send the requests in the sessions?
I would also like to capture the response and compare it to the baseline response, same as what WebAPI testing in Fiddler does.
Is there any sample programs that does something similar?
Please let me know if I should start a new thread instead of continuing on this one.
In general, I'd recommend that you use the APITest tab in Fiddler (see http://www.telerik.com/blogs/api-testing-with-telerik-fiddler).
FiddlerCore's object model provides many ways to send requests; the SendRequestAndWait method on the FiddlerApplication.oProxy object is probably the most common choice. When the call completes, you'd then use compare the oHeaders and responseBodyBytes properties of the returned response against the original Session and decide whether the test result met whatever criteria you have.
Regards,
Eric Lawrence
Telerik
Rank 1
Hi Eric,
Ok, thank you for the pointer. API testing is a wonderful feature!
Iris