[TIP] live coverage info during running program
Ned Batchelder
ned at nedbatchelder.com
Sat Jun 11 06:24:20 PDT 2016
You should be able to avoid os.system and use coverer.combine and
coverer.html_report, or at least make a new Coverage object to do it.
BTW: setting the object in the sys module is alarming. I wouldn't use
sys as a global scratchpad like that. You can just use your own module
that you import where you need it to hold a global object like that.
--Ned.
On 6/11/16 6:36 AM, Joel B. Mohler wrote:
> After reading the replies to my mail and the bitbucket ticket, I had a
> few more ideas. I now stop/save/start the Coverage object and the
> key is using the parallel support (aka data_suffix=True) for sake of
> getting cumulative results with a combine. In terms of the gui, the
> pause to stop/start is unnoticeable! I suppose it qualifies as a bit
> hacky, but so far it has given robust & reliable results.
>
> Here are my two code snips to make this work:
>
> import coverage
> cov = coverage.Coverage(data_suffix=True)
> cov.start()
> sys.coverer = cov
> my_program() # the stuff of interest
> cov.stop()
> cov.save()
> # should do a final combine & coverage generation here
>
> On an 8 second timer through-out the duration of the GUI I run the
> following method.
>
> def update_coverage_html(self):
> import os
> import threading
> def background_htmlify():
> # HACKY?! combine & html generation
> os.system("coverage combine")
> os.system("coverage html")
>
> if hasattr(sys, 'coverer'):
> sys.coverer.stop()
> sys.coverer.save()
> sys.coverer.start()
> t = threading.Thread(target=background_htmlify)
> t.start()
>
> Joel
>
> On 06/09/2016 08:28 AM, Ned Batchelder wrote:
>> This is a current limitation of these methods, as reported here:
>> https://bitbucket.org/ned/coveragepy/issues/448/save-and-html_report-prevent-further
>>
>> I haven't yet looked into what it would take to allow continued
>> collection after the save().
>>
>> --Ned.
>>
>> On 6/8/16 1:15 PM, Joel B. Mohler wrote:
>>> Dear Python testers,
>>>
>>> I'm trying to get a nice feedback loop for coverage testing both a
>>> Python REST
>>> server and the client side GUI program. I thought I could get
>>> coverage to
>>> produce an html report on some interval -- say every 5-10 seconds.
>>> This
>>> doesn't seem to be a documented use-case ... or is it?
>>>
>>> Following the documentation, I've inserted:
>>>
>>> import coverage
>>> cov = coverage.Coverage()
>>> cov.start()
>>> sys.coverer = cov # stash this in a global place
>>> my_program() # bunch of code
>>> cov.stop()
>>> cov.save()
>>> cov.html_report()
>>>
>>> Inside my_program (which is really a whole GUI event loop), I've
>>> kicked off a
>>> little chunk periodically to update the html:
>>>
>>> sys.coverer.save()
>>> sys.coverer.html_report()
>>> # attempt at hacking some result-caching by coverage
>>> sys.coverer._measured = True
>>>
>>> On the first time I come to my update-the-html code and I get an
>>> htmlcov
>>> directory that looks correct. On the second and subsequent times,
>>> it looks as
>>> though it rewrites exactly the same html.
>>>
>>> Is this possible? Is there other caching I need to defeat? There is
>>> file hash
>>> checking code in the HtmlReport which I do not fully understand.
>>>
>>> I understand this might be slow. I was hoping that I could get an
>>> up-to-date
>>> CoverageData object quickly then go htmlify it in the background.
>>> That looks
>>> difficult since the HtmlReport takes a Coverage object not a
>>> CoverageData.
>>>
>>> Thanks,
>>> Joel
>>>
>>> _______________________________________________
>>> testing-in-python mailing list
>>> testing-in-python at lists.idyll.org
>>> http://lists.idyll.org/listinfo/testing-in-python
>>
>>
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
More information about the testing-in-python
mailing list