Skip to main content

Jannis Leidel and Carl Meyer's django-discover-runner with coverage.

Project description

Adds coverage to Jannis Leidel and Carl Meyer’s django-discover-runner.

Inspired by django-coverage.

Usage

One of the objectives of django-discover-runner is to allow the separation of a Django app’s tests from the code it’s testing. Since tests no longer reside in an app, django-discoverage needs a different way to know which apps to include in the coverage report. The runner does this in two ways which are discussed below.

First, it tries to infer which apps you are testing from the name of the package in which the test’s module lives. For example, if you have an app blog and you test the view of the app in the module tests.blog.test_views, the app will be included in the coverage report. The same happens if the app is a subpackage and appears in INSTALLED_APPS as myproject.blog.

This behavior is controlled by the PKG_NAME_APP_DISCOVERY setting.

Although not on by default, tested apps can also be guessed from the name of the test’s module. For example, if MODULE_NAME_APP_DISCOVERY is True and there is a module named tests.test_blog, the blog app will be included in the report. You can override the regular expression used to extract the app name using the MODULE_NAME_DISCOVERY_PATTERN setting.

The second way in which django-discoverage finds apps is by looking for an iterable of app names (named by default TESTS_APPS) in three places:

  1. On a TestCase instance in the suite.
  2. In the TestCase subclass’s module (test*.py by default).
  3. In the TestCase subclass’s immediate package. If MyTestCase is in the package tests.myapp.test_views, the runner inspects tests.myapp. It does not currently traverse parent packages.

Let’s say you had the following test module, tests.blog.test_views:

TESTS_APPS = ('blog',)

class MyTestCase(TestCase):
    TESTS_APPS = ('mycoolapp', 'myproject.anothercoolapp')
    ...

All modules in the apps blog, mycoolapp, and myproject.anothercoolapp will be included in the report along with any apps listed in test.blog.TESTS_APPS.

Modules specified in OMIT_MODULES will not, however, appear in the report.

Settings

PKG_NAME_APP_DISCOVERY
Determines whether tested apps are guessed from a test module’s package name. It is on by default.
MODULE_NAME_APP_DISCOVERY
Determines whether tested apps are guessed from a test module’s name.
MODULE_NAME_DISCOVERY_PATTERN
A regular expression with a single capturing group that extracts the app name from a module name (e.g. “blog” from test_blog). Defaults to "test_?(\w+)".
TESTED_APPS_VAR_NAME
The name of the iterable django-discoverage looks for in the three places listed above. Defaults to TESTS_APPS.
OMIT_MODULES
Modules not to be traced by coverage. See the coverage API documentation for more details. Defaults to ['*test*'].

TODO

  • Add more settings to control coverage

Project details


Release history Release notifications

History Node

1.0.0

History Node

0.7.2

History Node

0.7.1

History Node

0.7.0

History Node

0.6.2

History Node

0.6.1

History Node

0.6.0

History Node

0.5.0

This version
History Node

0.4.0

History Node

0.3.1

History Node

0.3.0

History Node

0.2.1

History Node

0.2.0

History Node

0.1.0

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Filename, size & hash SHA256 hash help File type Python version Upload date
django-discoverage-0.4.0.tar.gz (5.0 kB) Copy SHA256 hash SHA256 Source None Oct 26, 2012

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging CloudAMQP CloudAMQP RabbitMQ AWS AWS Cloud computing Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page