[TIP] Coverage for the Django server

Shaheed Haque shaheedhaque at gmail.com
Sat Apr 27 07:08:29 PDT 2019


On Sat, 27 Apr 2019 at 07:57, Marius Gedminas <marius at gedmin.as> wrote:

> Um, I sent a reply to this on Apr 16.  Did it get stuck in some
> moderation queue?  Are my PGP signatures at fault?
>
> On Fri, Apr 26, 2019 at 09:37:38PM +0100, Shaheed Haque wrote:
> > Apologies for the bump, but I'm really stuck for what to try next.
> >
> > P.S. I did also email the Django list, but that was [1]similarly quiet.
> >
> >
> > On Tue, 16 Apr 2019 at 12:03, Shaheed Haque <[2]shaheedhaque at gmail.com>
> wrote:
> >
> >     Hi,
> >
> >     I'm trying to get coverage.py to generate results for code running
> >     under the Django server [1]. I expected that the initial difficulty
> >     would be with having the server exit in a manner which allowed the
> >     end-of-run coverage logic to get a chance to run. I hacked a solution
> >     to that [2], and I can now say
> >
> >     $ coverage -p manage.py runserver ...
>
> TL;DR is try passing --noreload to runserver.
>
> >     Though I could be mistaken, AFAIK, Django does not use any of the
> >     constructs which are known sources of incompatibility.
>
> It does: the Django autoreloader spawns a subprocess to run the actual
> view code (that gets killed and restarted every time the autoreloader
> detects source code changes).
>

Wow. Thanks for the hint, I'll give it a try!

Shaheed

Marius Gedminas
> --
> I doubt, therefore I might be.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20190427/6e64a701/attachment.html>


More information about the testing-in-python mailing list