On Fri, 2009-07-10 at 07:58 +0800, Russell Keith-Magee wrote:
> On Fri, Jul 10, 2009 at 3:23 AM, J. Cliff Dyer<j...@unc.edu> wrote:
> >
> > I'm trying to get my django site under tests.  I've started testing my
> > pages using Client('url/to/my/page'), but I noticed that each test takes
> > about a second to run (just to get a response code for the page--very
> > basic tests).
> 
> Are you using Django v1.1 or v1.0, and are you using Django's TestCase
> or the native unittest TestCase? The reason I ask is that the delay
> may be caused by the flushing of the database at the start of the
> test, rather than the client view invocation itself. Django v1.1
> improved this flushing time for databases that support transactions
> and rollbacks, but it will still be observable.
> 

I'm using 1.0.  I'll upgrade to 1.1 when I can, but for now I'm stuck
here.

> Python native unittests will always run much faster, since they have
> no setup/teardown overhead - but you also lose the nice fruit that
> Django's TestCase provides. However, you can reproduce that fruit -
> manually configure test fixtures, the client, etc - if test speed is a
> particular concern.
> 

I am using the django testcase, but without fixtures, because loading
fixtures is busted when you use a m2m relationship defined with an
explicit through table.  Ticket #11107 addresses this, and I've written
a patch for it which is marked ready for checkin, but with the push to
1.1, it hasn't gotten patched.  We will backport the patch, but for
various reasons, mostly having to do with support and funding, I'm loath
to get my sysadmins to patch it until it's in trunk somewhere.  

So in the meantime, the DB just has one object in it, which I'm creating
manually in setUp.

> > First of all, it seems like the client go through all the usual
> > apparatus of the django framework, including URLs, views, middlewares,
> > and templates.  Is this the case?
> 
> Correct. The test client is an attempt to validate the full stack for
> an installed view.
> 
> > This is useful, but also more of a functional test than a unit test.
> > I'd like to get tests going that can run faster, and properly test only
> > the view in question.  Does django provide any conveniences for this?
> 
> There isn't one built in right now, but there is an open ticket [1]
> that references a snippet that can help create mock Request objects.
> This snippet has been integrated as part of the GSoC project on
> testing, so it should be in trunk in the 1.2 timeframe.
> 
> [1] http://code.djangoproject.com/ticket/9002
> 

Oh cool.  That might be just the thing.  I'll take a closer look in the
morning.  And at the related snippet as well.

> > Failing that, I can probably manually instantiate a Request object, just
> > call the view function, and test the condition of the response object,
> > but I wanted to get some feedback on what others are doing, too.
> 
> This approach is also plausible.
> 
> Yours,
> Russ Magee %-)
> 
> > 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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