[TIP] Almad, testing Django Views (nyxtom at gmail.com)

nyxtom at gmail.com nyxtom at gmail.com
Thu Mar 17 12:17:44 PDT 2011


>> With Django, there
>> seems to be a tendency to exhaustively test views. This creates a
scenario
>> where your test integrates with context processors, middleware, database
>> filters and probably a number of other items you may be unaware of. In
>> short, if your test case isn't about integration or exhaustive
acceptance,
>> then mock out those areas that aren't required.

> May I ask how is it done at Your place?

> I end up basically unittesting underlying logic and testing views only
> through integration tests (aside from some "unit project" magic, where
> different-then-production settings are used).

> Do You have any easy take on how to mock, for example database backend?
> Thanks,
> Almad

What we end up doing is creating a MockQuerySet which effectively takes a
list as the alternative to
the filtering function. This creates a scenario where you can call
Model.objects.filter(bleh='asdf')....etc and
still have it returns a MockQuerySet instead.

Additionally, we tend to have things that trigger post_save signals, so we
will not only create mock query sets, but we ensure that
no actual saving is occurring to the database. This definitely takes a bit
of exhaustive setting up, but once you have it in place like
we do, all it takes it creating a new testcase that inherits from
NonPushTestCase. It's still rough around the edges, but for the most
part we can avoid calling any web services and database calls.


On Thu, Mar 17, 2011 at 3:00 PM,
<testing-in-python-request at lists.idyll.org>wrote:

> Send testing-in-python mailing list submissions to
>        testing-in-python at lists.idyll.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.idyll.org/listinfo/testing-in-python
> or, via email, send a message with subject or body 'help' to
>        testing-in-python-request at lists.idyll.org
>
> You can reach the person managing the list at
>        testing-in-python-owner at lists.idyll.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of testing-in-python digest..."
>
>
> Today's Topics:
>
>   1. Re: testing-in-python Digest, Vol 50, Issue 10 (Almad)
>   2. Problems getting coverage of a TurboGears application
>      (Richard Jones)
>   3. Re: Problems getting coverage of a TurboGears application
>      (Christoph Zwerschke)
>   4. Re: Problems getting coverage of a TurboGears application
>      (Ned Batchelder)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 16 Mar 2011 21:39:19 +0100
> From: Almad <bugs at almad.net>
> Subject: Re: [TIP] testing-in-python Digest, Vol 50, Issue 10
> To: testing-in-python at lists.idyll.org
> Message-ID:
>        <AANLkTimAxzkDo5YigRubL03OCOUEMXZQBUL7oDPXVe3b at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2011/3/15 nyxtom at gmail.com <nyxtom at gmail.com>:
> > With Django, there
> > seems to be a tendency to exhaustively test views. This creates a
> scenario
> > where your test integrates with context processors, middleware, database
> > filters and probably a number of other items you may be unaware of. In
> > short, if your test case isn't about integration or exhaustive
> acceptance,
> > then mock out those areas that aren't required.
>
> May I ask how is it done at Your place?
>
> I end up basically unittesting underlying logic and testing views only
> through integration tests (aside from some "unit project" magic, where
> different-then-production settings are used).
>
> Do You have any easy take on how to mock, for example database backend?
>
> > - Thomas
>
> Thanks,
>
> Almad
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 17 Mar 2011 16:42:03 +1100
> From: Richard Jones <r1chardj0n3s at gmail.com>
> Subject: [TIP] Problems getting coverage of a TurboGears application
> To: tip <testing-in-python at lists.idyll.org>
> Message-ID:
>        <AANLkTimumJTWJrkmt9nv0AJF0ecAA2X9dWwKwuWjXOB7 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> I have a TurboGears (1.1b3) application which has a bunch of code in a
> package that implements all the controller stuff.
>
> I have a bunch of tests that I execute with nosetests (yay nosetests!)
> using stdlib unittest.TestCase to organise them ('cos I roll it old
> school like that). The tests execute the code in the package directly
> - not through any TurboGears/cherrypy publishing, fake or otherwise.
>
> When I ask nosetests for coverage (--with-coverage) the modules in my
> package are listed, but they're always listed with 0% coverage.
>
> I've attempted to run the tests manually under coverage.py and when I
> do so the report doesn't list my package's modules at all!
>
> I use nose + coverage in a bunch of my other applications and it works
> fine there, it's just this one TurboGears application that's not
> working.
>
> Does anyone have any hints for where I might even start looking to fix
> this problem?
>
>
>     Richard
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 17 Mar 2011 12:05:28 +0100
> From: Christoph Zwerschke <cito at online.de>
> Subject: Re: [TIP] Problems getting coverage of a TurboGears
>        application
> To: testing-in-python at lists.idyll.org
> Message-ID: <4D81EAF8.6020305 at online.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Am 17.03.2011 06:42 schrieb Richard Jones:
>  > I have a TurboGears (1.1b3) application which has a bunch of code in a
>  > package that implements all the controller stuff.
>
> I wonder why you're still using a beta version of 1.1. 1.1 final and
> 1.1.2 bugfix versions are available and should be fully compatible.
>
>  > When I ask nosetests for coverage (--with-coverage) the modules in my
>  > package are listed, but they're always listed with 0% coverage.
>  > Does anyone have any hints for where I might even start looking to fix
>  > this problem?
>
> This has to do with conflicts between PEAK-Rules and coverage caused by
> their use of sys.settrace. Some things you should try:
>
> - Use coverage with the "--timid" option
>   or set timid=True in .coveragerc to activate
>   this option with the nose coverage plugin
> - Use Python >= 2.6 because of
>   http://bugs.python.org/issue1569356
> - Update to TurboGears 1.1.2 and the latest PEAK-Rules
>
> -- Christoph
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 17 Mar 2011 09:41:52 -0400
> From: Ned Batchelder <ned at nedbatchelder.com>
> Subject: Re: [TIP] Problems getting coverage of a TurboGears
>        application
> To: Christoph Zwerschke <cito at online.de>
> Cc: testing-in-python at lists.idyll.org
> Message-ID: <4D820FA0.5070703 at nedbatchelder.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> This is almost exactly the case the --timid flag was designed for.  For
> running under nose, make sure you have coverage.py >= 3.3, and create a
> .coveragerc file:
>
>     [run]
>     timid = True
>
> It will go slower, but it should measure properly.
>
> --Ned.
>
> On 3/17/2011 7:05 AM, Christoph Zwerschke wrote:
> > Am 17.03.2011 06:42 schrieb Richard Jones:
> > > I have a TurboGears (1.1b3) application which has a bunch of code in a
> > > package that implements all the controller stuff.
> >
> > I wonder why you're still using a beta version of 1.1. 1.1 final and
> > 1.1.2 bugfix versions are available and should be fully compatible.
> >
> > > When I ask nosetests for coverage (--with-coverage) the modules in my
> > > package are listed, but they're always listed with 0% coverage.
> > > Does anyone have any hints for where I might even start looking to fix
> > > this problem?
> >
> > This has to do with conflicts between PEAK-Rules and coverage caused
> > by their use of sys.settrace. Some things you should try:
> >
> > - Use coverage with the "--timid" option
> >   or set timid=True in .coveragerc to activate
> >   this option with the nose coverage plugin
> > - Use Python >= 2.6 because of
> >   http://bugs.python.org/issue1569356
> > - Update to TurboGears 1.1.2 and the latest PEAK-Rules
> >
> > -- Christoph
> >
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
> >
>
>
>
> ------------------------------
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
>
> End of testing-in-python Digest, Vol 50, Issue 13
> *************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20110317/82bb981a/attachment.htm>


More information about the testing-in-python mailing list