Re: Unit testing views.

2009-07-11 Thread J. Clifford Dyer 

Woot!  Thank you.  I'll be pestering my sysadmins about that starting
with our Tuesday meeting this week. :)

Cheers,
Cliff


On Sat, 2009-07-11 at 22:32 +0800, Russell Keith-Magee wrote:
> On Fri, Jul 10, 2009 at 1:02 PM, J. Clifford Dyer 
> wrote:
> >
> > 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 wrote:
> >> >
> > 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.
> 
> Since you asked so nicely, and since you've done a great job making
> the ticket easy to understand, I've slipped your fix for #11107 into
> trunk as of [11215], and the 1.0.X branch as of [11216] (and, for good
> measure, your name into the AUTHORS file).
> 
> Now you don't have an excuse for not upgrading :-)
> 
> 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
-~--~~~~--~~--~--~---

Re: Unit testing views.

2009-07-11 Thread Russell Keith-Magee 

On Fri, Jul 10, 2009 at 1:02 PM, J. Clifford Dyer wrote:
>
> 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 wrote:
>> >
> 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.

Since you asked so nicely, and since you've done a great job making
the ticket easy to understand, I've slipped your fix for #11107 into
trunk as of [11215], and the 1.0.X branch as of [11216] (and, for good
measure, your name into the AUTHORS file).

Now you don't have an excuse for not upgrading :-)

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
-~--~~~~--~~--~--~---

Re: Unit testing views.

2009-07-09 Thread J. Clifford Dyer 

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 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
-~--~~~~--~~--~--~---

Re: Unit testing views.

2009-07-09 Thread Russell Keith-Magee 

On Fri, Jul 10, 2009 at 3:23 AM, J. Cliff Dyer 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.

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.

> 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

> 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
-~--~~~~--~~--~--~---