django-nose

1.4.7 · maintenance · verified Thu Apr 16

django-nose is a Django test runner that integrates the capabilities of the Nose testing framework into Django's test suite. It provides features like testing only specified apps, running specific test modules/classes/tests, simplifying test discovery by obviating the need for `tests/__init__.py`, and leveraging Nose's plugin ecosystem. Additionally, it offers optional performance enhancements such as fixture bundling, reuse of test databases, and hygienic TransactionTestCases. The library is currently in maintenance mode (version 1.4.7) and was last updated in 2020. For new projects, the maintainers recommend considering `pytest` or `unittest` with Django's native testing framework.

Common errors

```
ImportError: No module named urls
```
cause When upgrading Django projects from <=1.3 to >=1.4, if a `__init__.py` file exists in the project's root directory (making it a Python package), `django-nose` might incorrectly try to load URL configurations from `my_project.my_project.urls`.

fix For Django 1.4+ projects, remove the `__init__.py` file from the project's root directory. Ensure any Python files previously in the root are moved to an appropriate application or configuration directory.
```
RuntimeError: Model class app.world.models.country.Country doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS
```
cause This error, or an `AlreadyRegistered` exception, can occur if models or admin classes are imported directly in an app's `__init__.py` file, confusing Django's test runner during app loading.

fix Avoid importing models or admin classes directly within `__init__.py` files. Instead, import them within the `ready()` method of your `AppConfig` (e.g., `from django.apps import AppConfig; class WorldConfig(AppConfig): name = 'world'; def ready(self): from .admin import countries`). Alternatively, ensure explicit `app_label` is set for models not within an `INSTALLED_APPS` defined application structure.
```
DatabaseError: no such table: django_site (or similar 'no such table' errors)
```
cause When using SQLite3 for testing, especially with plugins like `django-nose-selenium` (which builds on `django-nose`), the default in-memory SQLite database can lead to these errors because it's not persistent across certain test processes.

fix Explicitly define a `TEST_NAME` in your database settings to use a file-based SQLite database for testing instead of an in-memory one. For example: `DATABASES = {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': BASE_DIR / 'db.sqlite3', 'TEST': {'NAME': BASE_DIR / 'test_sqlite.db'}}}`.

Warnings

deprecated The `nose` project, on which `django-nose` relies, has been in maintenance mode since at least 2015. `django-nose` itself is also in maintenance mode, and its maintainer is no longer an active user. New projects are strongly advised to use `pytest` or Django's built-in `unittest` framework instead.
Fix: For new projects, consider `pytest` (e.g., `pytest-django`) or Django's `unittest` framework. For existing projects, evaluate migration or proceed with caution, acknowledging limited future support.
breaking Versions 1.4.4 and newer dropped support for Django 1.4-1.7 and Python 2.6. South support was also dropped in 1.4.4. Ensure your Django and Python versions are compatible with `django-nose` 1.4.7, which supports Django up to 2.2 and Python up to 3.7.
Fix: Upgrade Django and Python to supported versions (e.g., Django 2.2, Python 3.7) or pin `django-nose` to an older version compatible with your environment.
gotcha The `REUSE_DB=1` feature for reusing test databases has several open issues, including reports of data loss, and is not compatible with `TransactionTestCases` that do not clean up after themselves. It also requires manual disabling whenever your database schema changes to ensure reinitialization.
Fix: Use `REUSE_DB=1` with extreme caution. Ensure your `TransactionTestCases` are 'hygienic' (clean up database changes). Always run tests without `REUSE_DB=1` after schema migrations to reinitialize the database.
gotcha The `--with-fixture-bundling` option can cause test failures due to hidden order dependencies between tests or state leakage (e.g., locale activation, `memcached` contents) if not properly reset between tests. Post-save signal handlers creating additional data during fixture loading can also cause issues.
Fix: If experiencing failures with `--with-fixture-bundling`, consider disabling it or subclassing `django_nose.FastFixtureTestCase` only for tests that are confirmed to have no order dependencies. Ensure `setUp` and `tearDown` methods clear any non-database state.

Install

pip install django-nose Install from PyPI

Imports

NoseTestSuiteRunner
wrong:
```
TEST_RUNNER = 'django_nose.run_tests'
```
correct:
```
TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'
```
The `django_nose.run_tests` runner was deprecated and removed for Django versions 1.2+; `NoseTestSuiteRunner` is the correct class-based runner.

Quickstart

To quickly integrate `django-nose`, add `django_nose` to your `INSTALLED_APPS` and set `TEST_RUNNER` in your Django `settings.py` file. You can then run tests using `python manage.py test`. Additional Nose arguments can be specified via the `NOSE_ARGS` setting.

import os

# settings.py

INSTALLED_APPS = [
    # ... other apps
    'django_nose',
    # ... your project apps
]

TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'

# Optional: Configure Nose arguments (example with coverage)
NOSE_ARGS = [
    '--with-coverage',
    '--cover-package=your_app_name',
    '--cover-html-dir=coverage_report'
]

# Run tests from your project root:
# python manage.py test
# Or with specific app:
# python manage.py test your_app_name

view raw JSON →