Coverage not creating any output file

Issue #232 invalid
jalder
created an issue

When I try to run a component test of our testing framework, coverage is not willing to produce any output file (.coverage) and thus failes to generate a report. Apart from this, coverage is not reporting any errors.

qauser@foqa01:~/.jenkins/workspace/TAF-Test> coverage run TestCases/TAF/ComponentTests/CT_AlmApi.py
..<output>..
qauser@foqa01:~/.jenkins/workspace/TAF-Test> coverage xml
No data to report.

As this is our framework for component tests up to system integration tests there is quite some stuff happening in there... Do you have any advice on how to track this issue? Is there any verbose mode for coverage?

If I run coverage with a simple script it works perfectly, so the installation seems fine.

qauser@mqzhlfoqa01:~/.jenkins/workspace/TAF-Test> coverage debug sys
-- sys ----------------------------------------
        version: 3.6
       coverage: /usr/local/lib64/python2.6/site-packages/coverage-3.6-py2.6.egg/coverage/__init__.pyc
      cover_dir: /usr/local/lib64/python2.6/site-packages/coverage-3.6-py2.6.egg/coverage
     pylib_dirs: /usr/lib64/python2.6
         tracer: PyTracer
   config_files: .coveragerc
   configs_read: -none-
      data_path: /export/home/qauser/.jenkins/workspace/TAF-Test/.coverage
         python: 2.6 (r26:66714, Nov  9 2010, 01:31:57) [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
       platform: Linux-2.6.32.27-0.2-default-x86_64-with-SuSE-11-x86_64
 implementation: CPython
     executable: /usr/bin/python2.6
            cwd: /export/home/qauser/.jenkins/workspace/TAF-Test
           path: /usr/local/bin
                 /usr/local/lib64/python2.6/site-packages/setuptools-0.6c11-py2.6.egg
                 /usr/local/lib64/python2.6/site-packages/coverage-3.6-py2.6.egg
                 /usr/local/lib64/python2.6/site-packages/distribute-0.6.34-py2.6.egg
                 /export/home/qauser/.jenkins/workspace/TAF-Test
                 /usr/lib/python26.zip
                 /usr/lib64/python2.6
                 /usr/lib64/python2.6/plat-linux2
                 /usr/lib64/python2.6/lib-tk
                 /usr/lib64/python2.6/lib-old
                 /usr/lib64/python2.6/lib-dynload
                 /usr/lib64/python2.6/site-packages
                 /usr/local/lib64/python2.6/site-packages
                 /usr/local/lib64/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info
                 /usr/lib64/python2.6/site-packages/gtk-2.0
    environment: PYTHONPATH = .:/export/home/qauser/.jenkins/workspace/TAF-Test
                 PYTHONSTARTUP = /etc/pythonstart
                 PYTHONPATHBASE = /export/home/qauser/.jenkins/workspace/TAF-Test

PS: Thanks for all of this and keep up the good work!

Comments (13)

  1. jalder reporter

    I just noticed that if the execution of our test produces an exception (still handled inside the framework) coverage is producing an output file.

    Any ideas how to track this issue? What calls could influence coverage like this?

  2. Ned Batchelder repo owner

    The only odd thing I see in the "debug sys" output is that you are using PyTracer instead of CTracer, it looks like you couldn't compile the C extension on installation. That shouldn't produce the problem you are seeing, but you'll want to fix that, because it will slow down your test runs.

    Are you using any libraries for starting or stopping processes, or using exotic multi-threading techniques? A few of these are listed at http://nedbatchelder.com/code/coverage/trouble.html Anything unusual that you might be using in your library might be a clue.

  3. jalder reporter

    Just fixed the CTracer, thanks for the hint.

    I searched the code again and found some process stuff (multiprocessing (bad), subprocess (ok?), threading (ok?)) but those are all in some implementation classes and not in the framework code i execute with the component tests mentioned here.

    Apart from those I couldn't find any unusual modules.

    I'm really wondering why coverage isn't producing any data at all. Is this the default behavior if no executed code is traced?

  4. jalder reporter

    Here you are..

    qauser@mqzhlfoqa01:~/.jenkins/workspace/TAF-Test> coverage run TestCases/TAF/ComponentTests/CT_AdmMdMessages.py
    ...<output>...
    qauser@mqzhlfoqa01:~/.jenkins/workspace/TAF-Test> coverage debug data
    -- data ---------------------------------------
    path: /export/home/qauser/.jenkins/workspace/TAF-Test/.coverage
    has_arcs: False
    No data collected
    qauser@mqzhlfoqa01:~/.jenkins/workspace/TAF-Test> ls -la ./.coverage
    ls: cannot access ./.coverage: No such file or directory
    qauser@mqzhlfoqa01:~/.jenkins/workspace/TAF-Test> ls -la .coverage
    ls: cannot access .coverage: No such file or directory
    
  5. Ned Batchelder repo owner

    Is it possible that your program is interfering with writing the .coverage data file? When I run coverage and collect no data, I get a 48-byte .coverage file anyway, and also a warning during the run phases, "No data was collected". Is there any chance you can share the code your are running?

  6. jalder reporter

    Hey Ned. Sorry for the late response. Unfortunately I'm pretty busy with other stuff at work right now and I won't get back to the lovely python coding in the next days. I'll provide more information as soon as I can.

  7. Sorin Sbarnea

    The problem is quite simple, if any of the tests are changing the current directory, coverage will end-up using the wrong directory.

    The only solution to this is to make coverage determine the output directory before starting the tests.

  8. Ned Batchelder repo owner

    Sorin: that's not true. The "debug sys" output shows the path that coverage will use for the data file, even if the tests change the directory. Have you encountered problems with a changed directory?

    Coverage.py used to have a problem with changing directories, but it's been fixed for 3.5 years: see issue #24.

  9. Mark M Evans

    I have seen the .coverage file fail to be generated in our project (we import coverage and start()/stop() it programmatically). I have not fully debugged it, but what was happening was that Coverage._atexit handler was not being called in some scenarios. I've worked around it by explicitly calling save() and not relying on the atexit handler even though auto_data is True.

    Our project is rather complex, so I can't provide a simple code sample yet (and it seemed timing dependent.) We do have atexit handlers of our own as well as signal handlers.

    If I learn more, I'll pass it on. Just like everyone, I'm in the middle of a release cycle so it may be a while before I can look more deeply into it. :)

  10. Log in to comment