<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7655.5">
<TITLE>RE: [TIP] Testing Django with py.test</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Not sure if this helps, but if I am not mistaken, Django (which I am not familiar with) uses<BR>
buildout.<BR>
<BR>
We use buildout internally in conjunction with PyTest and specify pytest, pytest-cov and pytest-xdist<BR>
as part of our buildout file (see excerpt below). After running buildout, we end up with a py.test file<BR>
in the ./bin folder which has all the system path set to the buildout environment (pytest_testlink is a plugin<BR>
linking pytest to a testlink server).<BR>
<BR>
[buildout]<BR>
parts= pytest<BR>
find-links = <A HREF="http://testlink.eng.dolby.net:8080">http://testlink.eng.dolby.net:8080</A><BR>
<BR>
[pytest]<BR>
recipe = zc.recipe.egg<BR>
eggs = PyTL<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pytest<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pytest-xdist<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pytest-cov<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pytest_testlink<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ${project:eggs}<BR>
<BR>
Note: Xdist doesn't work for us at this time as we are not generating an interpreter as part of buildout but we are using the system one, hence instances of python started via execnet have no knowledge of the buildout environment. Should be easy to fix though via the xdist hooks.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: testing-in-python-bounces@lists.idyll.org on behalf of Brent Hoover<BR>
Sent: Tue 11/1/2011 12:16 PM<BR>
To: testing-in-python@lists.idyll.org<BR>
Subject: [TIP] Testing Django with py.test<BR>
<BR>
Hello,<BR>
<BR>
I apologize if this is an obvious question but I have searched in vain<BR>
for it for quite some time.<BR>
<BR>
I currently have over to 400 tests on my Django project that no longer<BR>
work because I am doing a small bit of Postgresql-specific code (after a<BR>
lot of time trying to avoid it). So I have written a test runner and<BR>
test case that skips the the db creation/teardown and substitutes an<BR>
already in place, empty copy of the db.<BR>
<BR>
The problem is that using my own runner I am back to the cruddy test<BR>
discovery that Django has and no reporting, coverage etc. I was using<BR>
django-nose but would like to switch to py.test but run into the simple<BR>
issue that I can't seem to figure out how to get py.test to run in the<BR>
Django-specific setup (e.g. inserting the project root into the front of<BR>
sys.path, importing settings, etc). So when I run my tests, py.test<BR>
finds them but all imports fail as the are all relative to the project<BR>
root. Making them absolute means nothing works when running the dev server.<BR>
<BR>
Where would be the &quot;hook&quot; point for pytest so that it does the little<BR>
hacks to make this work? Is this a best written as a plugin or just<BR>
something I can somehow put in my py.test config file?<BR>
<BR>
Your help would be very much appreciated.<BR>
<BR>
--<BR>
Brent Hoover<BR>
Senior Web Application Developer<BR>
AutoShepherd.com<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
testing-in-python mailing list<BR>
testing-in-python@lists.idyll.org<BR>
<A HREF="http://lists.idyll.org/listinfo/testing-in-python">http://lists.idyll.org/listinfo/testing-in-python</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>