"No data was collected" warning when importing package under test

Issue #348 new
Chris Jerdonek
created an issue

I'm experiencing odd behavior I'm hoping you can help with.

I'm invoking coverage like this--

$ coverage run --source=my_package scripts/run_tests.py && coverage report

My run_tests.py executes a function like this:

def main():
    unittest.TestProgram(module=None)

Everything works as expected. However, if I add import my_package to the top of run_tests.py, then I get coverage's "No data was collected" warning.

Is there a reason this doesn't work, and is there a way around it? Thanks.

Comments (8)

  1. Chris Jerdonek reporter

    I discovered something that might be related. It looks like this is tied to a file-system case issue. I'm running Mac OS X Yosemite 10.10.1, and I don't think my setup has anything out of the ordinary.

    I tried printing repr(my_package) from inside my tests.

    Without the import statement, I get--

    <module 'my_package' from '/Users/chris/dev/python/my_package/my_package/__init__.py'>
    

    And with the import statement--

    <module 'my_package' from '/Users/chris/Dev/python/my_package/my_package/__init__.py'>
    

    From the command-line--

    $ pwd
    /Users/chris/Dev/python/my_package
    $ python -c "import os; print(os.getcwd())"
    /Users/chris/dev/python/my_package
    

    With the import statement, I tried adding the following line as an experiment--

    my_package.__path__ = ['/Users/chris/dev/python/my_package/my_package']
    

    and then the warning went away. It started picking up some of the coverage, but not all of it.

  2. Chris Jerdonek reporter

    So to say more, it looks like '/Users/chris/Dev/python/my_package' is originally in sys.path, and then unittest adds the following to the beginning of sys.path (which is redundant because it refers to the same directory): '/Users/chris/dev/python/my_package'. Incidentally, this is a bit like how coverage also adds something to the beginning of sys.path -- also with the wrong case. This causes the difference in the casing of my_package's path depending on whether my_package is imported before or after unittest is run.

    In terms of coverage, it looks like the question is whether coverage should be able to recognize files as the same on case-insensitive OS'es (i.e. file systems) when the paths differ only in case.

    I think these threads are relevant because the issue is related:

    1. https://mail.python.org/pipermail/python-dev/2010-September/103823.html
    2. https://mail.python.org/pipermail/python-ideas/2010-September/008153.html
  3. Chris Jerdonek reporter

    Okay, it looks like it's not sufficient to address unittest's behavior because I believe coverage still computes the paths of the files under test as having the lowercase 'dev' variant.

    The only work-around I have found so far is to insert sys.path.insert(0, os.getcwd()) before the import my_package line in run_tests.py. This way my_package winds up with the (incorrect) lowercase variant of its path, in order to match what coverage determines the paths to be.

  4. Chris Jerdonek reporter

    The problem still occurs with version 4.0a5.

    $ coverage debug sys data
    -- sys -------------------------------------------------------
               version: 4.0a5
              coverage: /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4/site-packages/coverage/__init__.py
             cover_dir: /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4/site-packages/coverage
            pylib_dirs: /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
                tracer: CTracer
          file_tracers: -none-
          config_files: .coveragerc
                        setup.cfg
          configs_read: -none-
             data_path: /Users/chris/dev/python/my_package/.coverage
                python: 3.4.2 (default, Nov 12 2014, 18:23:59) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)]
              platform: Darwin-14.1.0-x86_64-i386-64bit
        implementation: CPython
            executable: /Users/chris/Dev/.virtualenvs/my_package/bin/python3.4
                   cwd: /Users/chris/dev/python/my_package
                  path: 
                        /Users/chris/Dev/python/my_package
                        /Library/Frameworks/Python.framework/Modules
                        /Users/chris/Dev/.virtualenvs/my_package/lib/python34.zip
                        /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4
                        /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4/plat-darwin
                        /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4/lib-dynload
                        /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
                        /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin
                        /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4/site-packages
           environment: PYTHONPATH = /Library/Frameworks/Python.framework/Modules
          command_line: /Users/chris/Dev/.virtualenvs/my_package/bin/coverage debug sys data
          source_match: -none-
     source_pkgs_match: -none-
         include_match: -none-
            omit_match: -none-
           cover_match: /Users/chris/Dev/.virtualenvs/my_package/lib/python3.4/site-packages/coverage
           pylib_match: /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
    -- data ------------------------------------------------------
    path: /Users/chris/dev/python/my_package/.coverage
    has_arcs: False
    
    5 files:
    /Users/chris/dev/python/my_package/my_package/__init__.py: 0 lines
    /Users/chris/dev/python/my_package/my_package/test/__init__.py: 0 lines
    /Users/chris/dev/python/my_package/my_package/test/support.py: 0 lines
    /Users/chris/dev/python/my_package/my_package/test/test_my_package.py: 0 lines
    /Users/chris/dev/python/my_package/my_package/test/test_my_package2.py: 0 lines
    
  5. Log in to comment