3.6b2 Breaks NoseXCover

Issue #224 resolved
Kevin Stone created an issue

Upgrading from 3.5.3 to 3.6b2 (via PyPI) breaks the coverage calculations generated by the nose plug-in, nosexcover.

Comments (14)

  1. Ned Batchelder repo owner

    Kevin, can you provide more details? How are they broken? Did you run them under 3.6b1?

  2. Kevin Stone reporter

    Sorry about the lack of details, just wanted to send a quick report since you pushed 3.6b2 to PyPI so it will likely affect many others as well who just pip install coverage like I had been doing without a version guard.

    I've been deploying from PyPI, so my code runs fine on 3.5.3. I haven't tried running under 3.6b1 (will try now). Basically, all my tests showed 0% coverage under 3.6b2.

    It looks like it works fine under 3.6b1 but not 3.6b2.

    Because I'm running coverage via several nose plugins (with are then run via django-nose), I don't have a lot of direct experience with coverage (sorry).

    Find attached some coverage.xml files running the same tests under different version of coverage.

    Here's my setup.cfg for running nosetests:

    [nosetests]
    with-doctest=1
    #verbosity=2
    with-xcoverage=1
    cover-erase=
    cover-package=subblime
    with-xunit=1
    exclude-dir=functional
    nocapture=
    with-progressive=1
    with-yanc=1
    with-xtraceback=1
    

    and my testing_requirements.txt (with the coverage version guard added):

    # For Testing
    factory_boy
    mock
    django-nose
    coverage<3.5.99
    nose-exclude
    nose-progressive
    nosexcover
    yanc
    xtraceback
    
  3. Tres Seaver

    I'm seeing a regression from 3.5.2 for my 'compoze' package.

    With coverage 3.5.2

        $ cd /tmp
        $ git clone git@github.com:tseaver/compoze.git
        ...
        $ cd compoze
        $ /opt/Python-2.6.8/bin/virtualenv /tmp/cv352
        ...
        $ /tmp/cv352/bin/python setup.py develop
        ...
        $ /tmp/cv352/bin/easy_install nose coverage==3.5.2
        ...
        $ /tmp/cv352/bin/nosetests --with-coverage
        ...
        TOTAL                568      0   100%   
        ----------------------------------------------------------------------
        Ran 142 tests in 0.535s
    
        $ /tmp/cv3.5.2/bin/coverage debug sys > /tmp/3.5.2-debug.txt
        $ /tmp/cv3.5.2/bin/coverage debug data >> /tmp/3.5.2-debug.txt
    

    With coverage 3.6.0b2::

        $ /opt/Python-2.6.8/bin/virtualenv /tmp/cv3.6
        ...
        $ /tmp/cv36/bin/python setup.py develop
        ...
        $ /tmp/cv36/bin/easy_install nose coverage
        ...
        $ /tmp/cv36/bin/nosetests --with-coverage
        ...
        TOTAL                568    568     0%   
        ----------------------------------------------------------------------
        Ran 142 tests in 0.309s
    
        $ /tmp/cv3.6/bin/coverage debug sys > /tmp/3.6-debug.txt
        $ /tmp/cv3.6/bin/coverage debug data >> /tmp/3.6-debug.txt
    

    Output from the 'debug' steps for each environment attached.

  4. Kevin Stone reporter

    I did a bisect of the repo trying to isolate the changeset that breaks, hope that helps to isolate the issue.

    The first bad revision is:
    changeset:   1374:4c7cc10d396f
    user:        Ned Batchelder <ned@nedbatchelder.com>
    date:        Sun Dec 09 15:50:39 2012 -0500
    summary:     Get meta-coverage working on sub-processes.
    
  5. Kevin Stone reporter

    The breakage is due to the following addition in coverage/control.py:468:

    +        # Combining is a kind of harvesting.
    +        self._harvested = True
    

    Reverting/removing this change fixes the issue.

  6. Diogo Baeder

    Hi,

    This is affecting me as well. I get these two behaviours:

    1. If I use --cover-erase, it wipes out the coverage and reports 0% coverage;
    2. If I use the "coverage run" command before nosetests, generate some reports, and then run nose with coverage again, it keeps using the same old reports no matter what I change in my project.

    These issues started to happen in 3.6b2; If I downgrade coverage to 3.6b1, it works fine (as expected).

  7. Ned Batchelder repo owner

    kitsunde: this issue is marked resolved. Could you open a new issue with instructions how I can reproduce the problem? Please include the version of coverage.py that you are using.

  8. Log in to comment