Code review comment for lp:~jkakar/launchpadlib/testing-support

> When I tried to write a branch like this in the past, I was always trying to
> test launchpadlib itself. My goal was to set up a dummy Launchpad web service
> and make sure that the Launchpad object sent the right HTTP requests when you
> manipulated it, and did the right thing with different HTTP responses from the
> dummy service.

My initial attempts at solving the problem I have (make it easy to
test applications that use launchpadlib) involved this kind of
thing, but I quickly realized that it was going to be very painful.

> I was judging your branch against these criteria, but you're doing something
> different. You don't dummy the Launchpad web service to test the Launchpad
> object; you dummy the Launchpad object to test other stuff. Your dummy object
> can't be used to test the Launchpad object except on a superficial level, but
> it is very useful for testing code that uses the Launchpad class. So I think
> it's good enough for what it does.

Right, FakeLaunchpad can't be used to test Launchpad in any
meaningful way. I would still like to explore the idea of writing
some set of integration tests to ensure that the FakeLaunchpad and
Launchpad objects behave the same way, but it's not exactly clear to
me what the best way to do that is yet.

> We all agree it would be better if tests ran against a real Launchpad
> instance, but that's slow and complicated, and running against an up-to-date
> WADL gets us most of the way there. So please continue with this work.

Great, thanks a lot!