Hi,

On Sat, Jan 23, 2010 at 11:55 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

> On Sat, Jan 23, 2010 at 6:40 PM, Malcolm Box <malcolm....@gmail.com>
> wrote:
> > Hi,
> >
> > I've got an existing unit test suite using the django.test.TestCase class
> > that exercises the HTTP interface of the site, but running under Django's
> > test harness.
> >
> > I'd like to turn this into a black-box test suite, using real HTTP to
> talk
> > to the server remotely.  Obviously some tests e.g. the assertTemplateUsed
> > test would be impossible, but most of my tests are of the form
> > client.put/client.get then assertContains/assertEquals.  These should be
> > easy to transfer to an integration-level test suite.
> >
> > Has anyone tried doing something like this or know of existing code that
> can
> > do it?
>
> It sounds like you've got a case of using the wrong shovel to nail in
> a screw. As the testing docs indicate, if you want to do live browser
> testing, you should use a live browser test tool like twill, Selenium
> or Windmill. Django's test client is a way to functionally invoke (and
> test) views as seen by Django. If you want a full integration level
> test suite, you should be looking at other tools.
>
>
That's a lovely metaphor, however I'm not sure I'm hammering a screw.  The
test cases in question are not for a browser-consumed pages, but for a REST
API.  For webpages I would indeed use Selenium or somesuch, but that's not
the case.

I have a big bunch of testcases of the form:

r = self.client.get('/api/function1/')
self.assertContains(r, 'blah')
data = json.loads(r.content)
# do more stuff to verify the JSON

There's nothing browser-ish here - it's all API level testing.

Re-writing these in another framework so I can test the same API when it's
on a server rather than just running under a local test harness seems wrong,
not least in terms of DRY.  But without it, I have a test gap if something
works under Django's server but not in deployed mod_python/mod_wsgi.  Can
you tell I've just been bitten by this problem?

What I'm thinking of is replacing the Django TestCase object with a new one
that implements get() and post() via urllib, and fakes up enough of the
HttpResponse object to make the tests work.

I thought this might be generally useful enough that someone might have
already done it, hence the posting.

There is a long standing ticket (#2879) that proposes to improve the
> integration of these tools with Django. This ticket wasn't quite trunk
> ready last time I looked at it, but I'm still in favor of the general
> idea it is advocating. However, but even without fixing that ticket,
> it is possible to use them - it's just not as clean as it could be.
>
>
And lo, it is the case!  Thanks for the pointer to this stuff - links from
it appear to do almost exactly what I want to be able to do, at least in
terms of talking to a separate server.

Cheers,

Malcolm

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to