[TIP] Coverage for the Django server

[Shaheed Haque]

Hi Sam,

On Sat, 27 Apr 2019 at 20:11, Samantha Zeitlin <samanthazeitlin at gmail.com>
wrote:

> Shaeed, did you try this? It looks like you might have to edit manage.py?
>
>
> https://stackoverflow.com/questions/24668174/how-to-test-coverage-properly-with-django-nose
>
> I'm pretty sure we were using coverage in one of my previous jobs, but my
> memory of the details is fuzzy now. I may be able to put you in touch with
> one of my former coworkers who might be able to help, if you're still
> stuck.
>
> Sam
>

Thanks, I'm familiar with that thread. As I mentioned, the first part of
the thread does not apply as I'm running the test via Selenium, not
"manage.py test". But I did try the edit to manage.py as "runserver" is
clearly invoked via it. It made no difference (I suspect that running it
under coverage, and arranging for a clean exit of the server is equivalent
to what the hacks to manage.py achieve).

I note however, that the --noreload may be the key here as suggested by
Marius.

I'll try that as soon as the weekend's firefight is out. With any luck, I
won't need to take up your kind offer.

Thanks again, Shaheed

testing-in-python-request at lists.idyll.org wrote:
>
> Send testing-in-python mailing list submissions to
> 	testing-in-python at lists.idyll.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.idyll.org/listinfo/testing-in-python
> or, via email, send a message with subject or body 'help' to
> 	testing-in-python-request at lists.idyll.org
>
> You can reach the person managing the list at
> 	testing-in-python-owner at lists.idyll.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of testing-in-python digest..."
>
>
> Today's Topics:
>
>    1. Re: Coverage for the Django server (Shaheed Haque)
>    2. Re: Coverage for the Django server (Marius Gedminas)
>    3. Re: Coverage for the Django server (Shaheed Haque)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 26 Apr 2019 21:37:38 +0100
> From: Shaheed Haque <shaheedhaque at gmail.com> <shaheedhaque at gmail.com>
> Subject: Re: [TIP] Coverage for the Django server
> To: testing-in-python at lists.idyll.org
> Message-ID:
> 	<CAHAc2jdTfO5t6A1mBriq-Nk1XJeECsr_2pmq3NYVd_a53YyOOQ at mail.gmail.com> <CAHAc2jdTfO5t6A1mBriq-Nk1XJeECsr_2pmq3NYVd_a53YyOOQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 similarly quiet<https://groups.google.com/d/msg/django-users/_kYGSeDQG0Q/FUlYshV_CAAJ> <https://groups.google.com/d/msg/django-users/_kYGSeDQG0Q/FUlYshV_CAAJ>.
>
>
> On Tue, 16 Apr 2019 at 12:03, Shaheed Haque <shaheedhaque at gmail.com> <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 ...
>
> and see a .coverage.xxx.yyy file created. Viewing the results of
> "coverage combine" in pycharm shows that the static parts of the code
> (e.g. class and function definitions) are covered, but none of the
> function bodies are covered! For example, in this fragment, the first
> 2 lines are green, but the third is red:
>
>     class CreateForm(forms.ModelForm):
>         def __init__(self, *args, **kwargs):
>             super().__init__(*args, **kwargs)
>
> Though I could be mistaken, AFAIK, Django does not use any of the
> constructs which are known sources of incompatibility. I also note
> that most references to using Django with coverage refer to running
> tests using Django's built-in test infrastructure ("python3 manage.py
> test --with-coverage") but like a recent thread on this list, I am
> running the tests separately (though in my case, they are Python
> Selenium based tests running under pytest).
>
> >From coverage.py's point of view, isn't Django just a normal Python
> server program? What might I be doing wrong? Any clues much
> appreciated.
>
> Thanks, Shaheed
>
> [1] My wider setup includes code running under Celery and so on, but I
> realise that has its own limitations with regard to coverage.py
> compatibility.
> [2] See https://groups.google.com/forum/#!topic/django-users/_kYGSeDQG0Q
> if needed.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20190426/955229f4/attachment.html> <http://lists.idyll.org/pipermail/testing-in-python/attachments/20190426/955229f4/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 27 Apr 2019 09:57:16 +0300
> From: Marius Gedminas <marius at gedmin.as> <marius at gedmin.as>
> Subject: Re: [TIP] Coverage for the Django server
> To: Shaheed Haque <shaheedhaque at gmail.com> <shaheedhaque at gmail.com>
> Cc: testing-in-python at lists.idyll.org
> Message-ID: <20190427065716.ql27aq6kyv7ztpvb at platonas>
> Content-Type: text/plain; charset=us-ascii
>
> 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> <[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).
>
> Marius Gedminas
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20190428/d43af186/attachment-0001.htm>