[TIP] Library supporting fixture composition: kt.testing

[Ian Cordasco]

On Tue, Mar 22, 2016 at 4:38 PM, Fred Drake <fred at fdrake.net> wrote:
> On Tue, Mar 22, 2016 at 2:09 PM, Ian Cordasco
> <graffatcolmingov at gmail.com> wrote:
>> How does this compare to https://github.com/testing-cabal/fixtures,
>> https://github.com/openstack/requests-mock, and
>> https://github.com/sigmavirus24/betamax?
>>
>> It seems like it is reinventing (perhaps without the benefit of
>> experience) the fixtures library and parts of other libraries might
>> not really be helpful.
>
> Hmm; it might not be so interesting.  I wasn't aware of the libraries
> you identified, and will take a look at them.
>
> There are two distinct aspects to kt.testing:
>
> 1. a model for fixture composition, which I was interested in since
> many of the fixtures I use want to provide APIs of their own, and

The fixtures library already allows for fixture composition via the
`useFixture` method.

> 2. the specific fixture for requests.  This is included both as an
> example and because we needed something like this for the project I'm
> working on these days.

At this point, it would be a matter of creating a fixture that would
be included in any of the libraries above for the fixtures library.
You wouldn't need to duplicate the efforts then (or maintain this).

> The requests fixture is fairly simple; something better might include
> support for other web-requesting front-end APIs (urllib, urllib2,
> etc.), since for most tests the point is to make sure the request is
> mocked appropriately, without concern for which API the application
> actually uses to make the request. Maybe there's already a package
> that does that.

If you want something that's very generic, there are a lot more of
those libraries.

- httpretty
- vcr.py

Come to mind very quickly.

To be clear, I'm not particularly upset with the fact you wrote this.
Just pointing out that there are alternatives that are already in use
and well-supported.

Cheers!