#25209: coverage html doesn't work as documented
-----------------------------------+------------------------------------
Reporter: pzrq | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by pzrq):
@aaugustin
TLDR My PR is currently removing one line. I'll happily put the `coverage
combine` documentation and a revert of that one line removal (i.e.
basically option 2) together tomorrow at PyConAU sprints if you think it
will be useful for your parallel test runner.
But unless that's coming really soon it would be nice to restore the
documentation to a more consistent state as Django does pride itself on
documentation being a first class citizen.
----
https://github.com/django/django/compare/master...aaugustin:parallelize-
tests-attempt-1
That looks really really cool!
I just wonder if how likely it is to make the Django 1.9 alpha around mid
September 2015?
(Using as the guide Django 1.8 which took 2.5 months from alpha to
release, and I fully appreciate that question may be impossible to answer
until 1.9 alpha comes with or without it).
In any case it's a lot grander in scope than my attempt so far (`discover-
road-runner`) - I usually use it dozens of times a day and it works
wonders for my TDD productivity and testing other developers work more
quickly (without needing `--nomigrations` in `django-test-without-
migrations`); but it doesn't handle not-in-memory DBs, live application
servers, file upload, etc. And I'd be the first to admit it's a kludge to
generate test output cleanly and quickly (but has the benefit of not
needing to pickle things like tracebacks if you print them straight away),
and handle the really expensive migrations step better. With any luck OSX
10.11 El Capitan will mean you won't have to worry about all the headaches
of the builtin `multiprocessing` module under OSX Python 2.7.6 at least (a
colleague suggested I use the `billiard` fork entirely due to the time I
have spent wrangling `multiprocessing` and `sqlite3` crashes which AFAIK
are fixed upstream and certainly in Python 3.4). I guess this is just a
longer way of saying good luck - parallelism can be very challenging and
fun!
--
Ticket URL: <https://code.djangoproject.com/ticket/25209#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/062.ab113766f799622cde0f5bdb6dd69824%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
