Re: [Launchpad-users] How do you TDD a launchpadlib application?

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

On Thu, 2009-09-24 at 10:50 +0100, Jonathan Lange wrote:
> Hello Launchpad Users,
> 
> I've started to write things that use launchpadlib that are more than
> just throw-away scripts. I want to build these apps with test-driven
> development, which is my preferred way of writing serious code.
> 
> It turns out that it's really quite tricky. I've ended up making fake
> Bug objects and fake Person objects and all sorts of yuck. Has anyone
> done TDD with launchpadlib? What was your approach?

Can you share the tests you wrote, with the fake Bug objects etc.?

IMO making a dummy Launchpad for testing purposes is a sucker's game,
for two reasons. First, the Launchpad web service is about as
complicated as Launchpad. Second, if someone changes the web service,
your script's tests ought to start failing. The simplest way to deal
with these issues is to treat Launchpad as a testing dependency. Now
that Launchpad is open source, the only reason not to do this is that
Launchpad is friggin huge.

Assuming the tests run against a real Launchpad, should they run against
a locally installed Launchpad or against staging.launchpad.net? I think
it has to be a locally installed Launchpad, because otherwise you have
no guarantee of a consistent dataset.

Right now launchpadlib's tests make HTTP requests to
http://launchpad.dev/, and assume that you have already did a "make run"
for Launchpad. Instead, we could have launchpadlib's test setup create a
WSGI intercept for launchpad.dev, so that launchpadlib's HTTP requests
don't actually go out over the wire. This will reduce latency and avoid
the need to actually have Launchpad running ahead of time. (We do
basically this for lazr.restfulclient, where most of the launchpadlib
code lives, but its tests use one of lazr.restful's example web services
instead of Launchpad's.)

I like Tommaso's/Martin Fowler's self-initializing fake for speed, but
for the sake of consistency, it should be running against a local
Launchpad with a known dataset. That way you can choose to run the
"slow" test occasionally and make sure that changes to Launchpad haven't
broken your script.

Leonard

Attachment: signature.asc
Description: This is a digitally signed message part