<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 11/01/2011 12:55 PM, Brack, Laurent P. wrote:
    <blockquote
cite="mid:05BB196AB3DA6C4BBE11AB6C957581FE3E97512B@sfo-exch-01.dolby.net"
      type="cite">
      <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>
      <!-- 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>
        </font></p>
    </blockquote>
    <br>
    Django does not use buildout. I believe the Django dev team does use
    buildout for their CI server, but it's no in any way part of the
    standard set up and I don't know a lot of Django people who are.
    Also, I don't use it either as virtualenv and a pip requirements.txt
    gives me everything I need. Not against using whatever is required
    to get a good environment, but seems like an awful large amount of
    ramp-up to just have a couple hooks. Though it would probably have
    other advantages I am not aware of.<br>
    <blockquote
cite="mid:05BB196AB3DA6C4BBE11AB6C957581FE3E97512B@sfo-exch-01.dolby.net"
      type="cite">
      <p><font size="2">
          <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 moz-do-not-send="true"
            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: <a class="moz-txt-link-abbreviated" href="mailto:testing-in-python-bounces@lists.idyll.org">testing-in-python-bounces@lists.idyll.org</a> on behalf of
          Brent Hoover<br>
          Sent: Tue 11/1/2011 12:16 PM<br>
          To: <a class="moz-txt-link-abbreviated" href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><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 "hook" 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>
          <a class="moz-txt-link-abbreviated" href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
          <a moz-do-not-send="true"
            href="http://lists.idyll.org/listinfo/testing-in-python">http://lists.idyll.org/listinfo/testing-in-python</a><br>
          <br>
        </font>
      </p>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Brent Hoover
Senior Web Application Developer
AutoShepherd.com</pre>
  </body>
</html>