[TIP] Coverage for the Django server

[Shaheed Haque]

On Sat, 27 Apr 2019 at 15:08, Shaheed Haque <shaheedhaque at gmail.com> wrote:

>
>
> 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.
>>
>
I finally got back to this, and confirmed that having definitely tried with
--noreload I still get coverage "green" only for the static parts of the
code (i.e. class definitions and the like), while coverage of actual
executable code inside methods/functions is completely missing ("red").

To be explicit, I ran django like this (i.e. as an argument to a subprocess
call):

    ['coverage', 'run', '-p', 'manage.py', 'runserver', '--noreload', '
0.0.0.0:8000']

and the end-of-run signal to the server process to exit ends up calling:

    import _thread
    _thread.interrupt_main()

(this being the recipie that Google came up with for exiting Django), which
ends up dumping a file with a name like

    .coverage.<hostname>.8318.928006

I then run "coverage combine" and view the results in PyCharm (hence the
red and green colours).

Perhaps the manner of the exit is the problem? Is there a way to get the
coverage object needed to call the stop() and save() API methods?

Thanks, Shaheed


>
>> >     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/20190530/0c1206cd/attachment.html>