[TIP] vcr

Ron DuPlain ron.duplain at gmail.com
Wed Mar 28 06:18:23 PDT 2012

On Tue, Mar 27, 2012 at 11:39 AM, Andrea Crotti
<andrea.crotti.0 at gmail.com> wrote:
> On 03/27/2012 02:24 PM, vanderson.mota at gmail.com wrote:
>> VCR, as far as i know only works for HTTP. It is very easy to use, and
>> unfortunately i didn't find a match for it in python. It seems people are
>> more concerned about building "My new cool ruby-like test runner".
>> The coding strategy to make VCR was to monkeypatch the Http Libraries,
>> like the basic Net::Http, since there are a lot of http clients use it under
>> the hood. And for the ones who don't, the author wrote an adapter for the
>> most popular ones[1].
>> I think similar approach can be used with python.
>> 1: https://github.com/myronmarston/vcr/tree/master/lib/vcr/library_hooks
> Yes it should be feasible, and true it seems that the Ruby community has
> much more ferment in this area.
> Anyway it would be great to do the same thing recording directly the TCP/IP
> streams.
> There are probably a few problems with that:
> 1. need to be root to sniff the network traffic
> 2. might need to rewrite a lot of packets when replaying because they depend
> on the specific
>    network configuration of the machine
> so maybe it's not really easy after all, what do you think?

For testing request-response at the TCP level, I prefer to write tests
which have explicit examples instead of network replay.  I'll manually
run wireshark during a run, "Follow TCP Stream" in a wireshark capture
file, then copy over the requests/responses I'm interested in testing:

    example_request = """

    example_response = """

A mixin to TestCase could then parse these examples and make various
assertions.  This approach addresses for me the two concerns you

1. I have myself in the wireshark group and do not use root.
2. I can edit the examples based on the test attributes.

I use this kind of test structure to verify that my request builders
are building the TCP-level bytes correctly and my response parsers are
handling the responses.  In my opinion, this ends up far more
manageable and explicit than a replay approach.


More information about the testing-in-python mailing list