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