Dynamic coverage metrics for nested projects using globs

Issue #656 closed
Kevin Phillips created an issue

This may be a feature enhancement or a general query, depending on whether coverage currently supports this use case.

First let me give some background. I typically use pytest and tox to orchestrate my tests, and I typically use pytest-cov plugin to interact with coverage for calculating metrics. Further, I typically structure my projects with one main subfolder named ./src which contains 1 or more sub-folders for each package in my project.

So my issue is, I'd like some way to generate code coverage metrics for any / all sub-packages defined in the ./src folder, ideally without having to name them all by name. So, for example, if I have 3 sub-packages "./src/package1", "./src/package2" and "./src/package3" I'd like to be able to generate code coverage metrics on all 3 sub-projects by just doing something like "pytest --cov=src/*" or something similar, without having to list each project explicitly by name.

The main reason I'm trying to do this is because I'd like to be able to create a template script / config file that I could use across all my projects without having to go through the scripts and look for names of packages and update them manually. Also, when I rename a package or add/remove packages from a project I'd like the scripts to "just work" without having to remember to go back and update the configuration files to reflect the changes.

Any help you can provide would be greatly appreciated.

Comments (3)

  1. Ned Batchelder repo owner

    Have you tried a shell script which can loop over the subdirectories, running "coverage report --include=${here}" (or something like it) for each one?

  2. Kevin Phillips reporter

    Hmmm ... this would likely be a non-trivial task. First, in order to make the scripts cross-platform compatible I'd likely need to write another Python script that could do the work since shell scripts are not cross-platform compatible. But then, even if I worked out a solution for that, I'd likely need to re-run the test suite in it's entirety, once for each sub-package so the metrics could be reliably calculated. That would be less than ideal for several reasons, not the least of which would be the impact it would have of the performance of the build.

    Maybe if there were some way to generate the metrics once and then pre-process the metric data to separate the data by sub-folder or something... but then, that's probably more-or-less what would need to be done under the hood in the coverage library to accomplish the same task. At least if it were done in the core library then the solution could be re-used by others who may have a similar use case.

  3. Log in to comment