[TIP] coverage.py against a server

Ned Batchelder ned at nedbatchelder.com
Tue Sep 24 06:12:42 PDT 2013


On 9/24/13 7:31 AM, Lucian Ciufudean wrote:
> Back again, it does not work, neither with a relative or absolute path 
> in .coveragerc
>
> [root at spahire pyc]# coverage erase
> [root at spahire pyc]# ls -la
> total 28
> drwxr-xr-x. 2 root root 4096 Sep 24 12:28 .
> drwxr-xr-x. 4 root root 4096 Sep 17 15:58 ..
> -rw-r--r--. 1 root root  105 Sep 18 14:02 api.py
> -rw-r--r--. 1 root root   50 Sep 24 12:24 .coveragerc
> -rw-r--r--. 1 root root   28 Sep 18 13:01 main.py
> -rw-------. 1 root root  187 Sep 17 15:59 test_coverage_callee.pyc
> -rw-------. 1 root root  212 Sep 17 15:59 test_coverage_caller.pyc
> [root at spahire pyc]# cat .coveragerc
> [run]
> parallel = true
>
> [paths]
> mysources = ../src

Hmm, it looks like there's a little more work for me in coverage.py.  I 
had meant for your [paths] section to have two lines in the value: one 
with "../src", and one with a single dot: "." . Like this:

     [run]
     parallel = true

     [paths]
     mysources =
         ../src
         .

This tells "coverage combine" that when it encounters a path to a file 
in the current directory, it should remap it to ../src instead.  BUT: 
relative paths don't work!  If you put an absolute path in for the 
second entry, it will work:

     [paths]
     mysources =
         ../src
         /Users/ned/foo/run

I've created a ticket to track the fix for relative paths: 
https://bitbucket.org/ned/coveragepy/issue/267/relative-path-aliases-dont-work

This has been a very productive exchange! Three tickets! Thanks for 
finding these problems, sorry it couldn't have been flawless from the 
start..

--Ned.
> [root at spahire pyc]# coverage run main.py
> 1
> 2
> 2.1
> 2.2
> 2.3
> [root at spahire pyc]# coverage combine
> [root at spahire pyc]# coverage report
> Name                   Stmts   Miss  Cover
> ------------------------------------------
> main                       1      0   100%
> test_coverage_callee   NoSource: No source for code: 
> '/root/lucian/coverage/module1/pyc/test_coverage_callee.py'
> test_coverage_caller   NoSource: No source for code: 
> '/root/lucian/coverage/module1/pyc/test_coverage_caller.py'
>
> Lucian
>
>
>
> On Thu, Sep 19, 2013 at 2:43 AM, Ned Batchelder <ned at nedbatchelder.com 
> <mailto:ned at nedbatchelder.com>> wrote:
>
>     On 9/18/13 9:10 AM, Lucian Ciufudean wrote:
>>     Sorry for all these iterations, here is a more consistent (but
>>     long) email.
>>
>     Iterations are fine as long as they bring more detail! Thanks for
>     putting in all the work.
>
>
>>     After not being able to run 'coverage run pyc_file.pyc', I
>>     created a dummy driver main.py file that uses the compiled modules.
>>
>>     root at spahire pyc]# ls -la
>>     total 20
>>     drwxr-xr-x. 2 root root 4096 Sep 18 13:20 .
>>     drwxr-xr-x. 4 root root 4096 Sep 17 15:58 ..
>>     -rw-r--r--. 1 root root   28 Sep 18 13:01 main.py
>>     -rw-------. 1 root root  187 Sep 17 15:59 test_coverage_callee.pyc
>>     -rw-------. 1 root root  212 Sep 17 15:59 test_coverage_caller.pyc
>>     [root at spahire pyc]# cat  main.py
>>     import test_coverage_caller
>>
>>     The source files for the 2 pyc files are here:
>>
>>     [root at spahire pyc]# ls ../src
>>     test_coverage_callee.py  test_coverage_caller.py
>>
>>     Further, I run coverage, I get a warning but a data file
>>     .coverage is created:
>>
>>     [root at spahire pyc]# coverage run --source=../src main.py
>>     1
>>     2
>>     2.1
>>     2.2
>>     2.3
>>     Coverage.py warning: No data was collected.
>>     [root at spahire pyc]# ls -l .coverage
>>     -rw-r--r--. 1 root root 180 Sep 18 13:23 .coverage
>>
>     The --source option tells coverage that the only files of interest
>     are the ones in ../src.  You never execute any files in ../src, so
>     coverage hasn't collected any data.
>
>
>>     --include does not make a difference:
>>
>>     [root at spahire pyc]# coverage run --source=../src --include='*'
>>     main.py
>>     1
>>     2
>>     2.1
>>     2.2
>>     2.3
>>     Coverage.py warning: No data was collected.
>>     [root at spahire pyc]# ls -l .coverage
>>     -rw-r--r--. 1 root root 180 Sep 18 13:38 .coverage
>>
>     Right, --source trumps --include.  You've already told coverage
>     that the only interesting files are in ../src, so there's nothing
>     else to include.  I should make a warning for inconsistent options
>     like this (ticket:
>     https://bitbucket.org/ned/coveragepy/issue/265/when-using-source-include-is-silently)
>
>
>
>>     As expected, report shows nothing is covered:
>>
>>     [root at spahire pyc]# coverage report --include='*test*'
>>     Name                 Stmts   Miss  Cover
>>     ----------------------------------------------------------------------------
>>     /root/lucian/coverage/module1/src/test_coverage_callee       3  
>>        3     0%
>>     /root/lucian/coverage/module1/src/test_coverage_caller       3  
>>        3     0%
>>     ----------------------------------------------------------------------------
>>     TOTAL                    6      6     0%
>>
>>     report does not accept --source, might this be the root to all evil?
>>
>     Hmm, that seems like an oversight: I should make that possible
>     (ticket:
>     https://bitbucket.org/ned/coveragepy/issue/266/report-command-doesnt-accept-source-option)
>
>
>>     [root at spahire pyc]# coverage report --include='*test*'
>>     --source=../src
>>     no such option: --source
>>     Use 'coverage help' for help.
>>
>>     No warning when using run without options, but the report is
>>     again wrong:
>>
>>     [root at spahire pyc]# coverage run main.py
>>     1
>>     2
>>     2.1
>>     2.2
>>     2.3
>>     [root at spahire pyc]# coverage report
>>     Name                   Stmts   Miss  Cover
>>     ------------------------------------------
>>     main                       1      0 100%
>>     test_coverage_callee   NoSource: No source for code:
>>     '/root/lucian/coverage/module1/pyc/test_coverage_callee.py'
>>     test_coverage_caller   NoSource: No source for code:
>>     '/root/lucian/coverage/module1/pyc/test_coverage_caller.py'
>>
>     The problem is that you haven't told coverage how to find the
>     source files that correspond to your .pyc files.  The --source
>     option doesn't do that.
>
>
>>     Same thing with a configuration file:
>>     [root at spahire pyc]# cat .coveragerc
>>     [run]
>>     source=../src/
>>     include=*
>>
>     Right, same options, specified in a different way.
>
>>     So now I turn to the api + the same .coveragerc, the same thing:
>>
>>     [root at spahire pyc]# cat api.py
>>     import coverage
>>     cov = coverage.coverage()
>>     cov.start()
>>     import test_coverage_caller
>>     cov.stop()
>>     cov.save()
>>
>>     [root at spahire pyc]# python api.py
>>     1
>>     2
>>     2.1
>>     2.2
>>     2.3
>>     Coverage.py warning: No data was collected.
>>
>     Another run with the same (non-)options.
>
>
>>     As for your suggestion with [paths], the docs suggest to me that
>>     this is for combining data.
>     Yes, it is used when combining data, I should have fleshed out my
>     idea more fully.  Try creating a .coveragerc file like this:
>
>         [run]
>         parallel = true
>
>         [paths]
>         mysources =
>             ../src
>             .
>
>     Then use "coverage run main.py", then "coverage combine", then
>     "coverage report".  If that works, we can talk about how to make
>     it a bit easier.
>
>     Hope that helps,
>
>
>     --Ned.
>
>>
>>     Lucian
>>
>>
>>
>>     On Wed, Sep 18, 2013 at 1:20 PM, Ned Batchelder
>>     <ned at nedbatchelder.com <mailto:ned at nedbatchelder.com>> wrote:
>>
>>         On 9/18/13 3:42 AM, Lucian Ciufudean wrote:
>>>         Here is how I ran coverage:
>>>
>>>             coverage run --source=../src main.py
>>>
>>>         main.py imports a pyc file that resides in the same folder.
>>>         The source of this pyc file is available in ../src.
>>>         (I created main.py just to go around the bug that you
>>>         submitted above)
>>>
>>         You don't mention the exact errors you saw (details matter),
>>         but in your previous message you mentioned the problem being
>>         while reporting.  You'll also have to specify the source
>>         directory during the "coverage html" command (or
>>         coverage.html() call).  A good way to do this is with a
>>         .coveragerc file.
>>
>>         --Ned.
>>
>>
>>>         Lucian
>>>
>>>
>>>         On Wed, Sep 18, 2013 at 5:05 AM, Ned Batchelder
>>>         <ned at nedbatchelder.com <mailto:ned at nedbatchelder.com>> wrote:
>>>
>>>             On 9/17/13 7:42 AM, Lucian Ciufudean wrote:
>>>>             Hi guys,
>>>>
>>>>             I embarked on the road of obtaining a coverage report
>>>>             for functional tests against a server process. The
>>>>             server is deployed as .pyc files, and the source files
>>>>             can be made available in a separate subversion working
>>>>             folder. I wouldn't want to edit any existing .py files.
>>>>
>>>>             Can coverage work with .pyc files - I am getting errors
>>>>             when using coverage run main.pyc from the command line,
>>>>             so maybe with the API?
>>>
>>>             Hmm, you're right: "coverage run foo.pyc" does not work.
>>>             I've created a ticket for this:
>>>             https://bitbucket.org/ned/coveragepy/issue/264/coverage-wont-run-pyc-files
>>>
>>>
>>>
>>>>             I tired this also, my custom code is run but it can not
>>>>             find the source files at the time of
>>>>             coverage.html_report() although I passed the directory
>>>>             of source files to coverage.coverage.
>>>
>>>             You'll have to show details of how you tried to run
>>>             coverage.  If the .py files are in the places reported
>>>             by your program, then it should work.  You can also use
>>>             the [paths] section of a .coveragerc to instruct
>>>             coverage where the files are.
>>>
>>>             --Ned.
>>>
>>>>
>>>>             Thanks a lot,
>>>>             Lucian
>>>>
>>>>
>>>>             _______________________________________________
>>>>             testing-in-python mailing list
>>>>             testing-in-python at lists.idyll.org  <mailto:testing-in-python at lists.idyll.org>
>>>>             http://lists.idyll.org/listinfo/testing-in-python
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20130924/f0e90c6d/attachment-0001.htm>


More information about the testing-in-python mailing list