[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