Search code examples
pythondjangodjango-testingcoverage.py

Django reusable app testing - coveragerc


I'm developing a Django reusable app. My development setup looks like this:

~/development/django-foo/
    foo/
        apps.py
        fixtures/
            ...
        forms/
            ...
        __init__.py
        models/
            ...
        static/
            foo/
                ...
        templates/
            foo/
                ...
        tests/
            ...
        urls.py
        views/
            ...
    .gitignore
    README.rst

~/virtualenv/foo/
    ...
    project_root/
        apps/
            __init__.py
            foo -> ~/development/django-foo/foo/
        manage.py
        project/
            __init__.py
            settings/
            urls.py
            wsgi.py
        static/
        templates/

I want to include a .coveragerc which contains specific settings for my app, like special exclude_lines (described here). Obviously, this should be specific for my app, so I'd like to place that file in ~/development/django-foo/.coveragerc. Anyway, coverage is installed inside the virtualenv and the standard call would be

(foo) ~/virtualenv/foo/ % coverage run --source='apps/foo' manage.py test foo && coverage report

As stated, I want to make use of a .coveragerc, according to the docs,

The default name for configuration files is .coveragerc, in the same directory coverage.py is being run in.

I would like coverage to look for that config file in another location or even better, find it on its own depending on the tested app.

Is there any common approach or should I write my own test-runner with coverage integration?

And yes, the idea of symlinking ~/virtualenv/foo/project_root/.coveragerc to ~/development/django-foo/.coveragerc already came to my mind!


Solution

  • Yeah, more reading would have prevented this question:

    coverage help run
    ...
    --rcfile=RCFILE       Specify configuration file.  Defaults to '.coveragerc'
    

    I would still like to leave this open for other answers, especially regarding automatic discovery of app specific configuration files.