{"id":16847639,"url":"https://github.com/fabiosantoscode/django-nose-123-fix","last_synced_at":"2025-03-18T07:17:41.205Z","repository":{"id":9062264,"uuid":"10831076","full_name":"fabiosantoscode/django-nose-123-fix","owner":"fabiosantoscode","description":"proposed fix for #123 in django-nose","archived":false,"fork":false,"pushed_at":"2013-06-20T22:43:04.000Z","size":292,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-01-17T22:44:57.172Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/fabiosantoscode.png","metadata":{"files":{"readme":"README.rst","changelog":"changelog.txt","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2013-06-20T22:42:04.000Z","updated_at":"2013-12-05T14:31:39.000Z","dependencies_parsed_at":"2022-09-13T07:01:50.502Z","dependency_job_id":null,"html_url":"https://github.com/fabiosantoscode/django-nose-123-fix","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fabiosantoscode%2Fdjango-nose-123-fix","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fabiosantoscode%2Fdjango-nose-123-fix/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fabiosantoscode%2Fdjango-nose-123-fix/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fabiosantoscode%2Fdjango-nose-123-fix/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/fabiosantoscode","download_url":"https://codeload.github.com/fabiosantoscode/django-nose-123-fix/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244173553,"owners_count":20410300,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-13T13:08:36.659Z","updated_at":"2025-03-18T07:17:41.182Z","avatar_url":"https://github.com/fabiosantoscode.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"===========\ndjango-nose\n===========\n\n.. image:: https://travis-ci.org/jbalogh/django-nose.png\n  :target: https://travis-ci.org/jbalogh/django-nose\n\nFeatures\n--------\n\n* All the goodness of `nose`_ in your Django tests, like...\n\n  * Testing just your apps by default, not all the standard ones that happen to\n    be in ``INSTALLED_APPS``\n  * Running the tests in one or more specific modules (or apps, or classes, or\n    folders, or just running a specific test)\n  * Obviating the need to import all your tests into ``tests/__init__.py``.\n    This not only saves busy-work but also eliminates the possibility of\n    accidentally shadowing test classes.\n  * Taking advantage of all the useful `nose plugins`_\n* Fixture bundling, an optional feature which speeds up your fixture-based\n  tests by a factor of 4\n* Reuse of previously created test DBs, cutting 10 seconds off startup time\n* Hygienic TransactionTestCases, which can save you a DB flush per test\n* Support for various databases. Tested with MySQL, PostgreSQL, and SQLite.\n  Others should work as well.\n\n.. _nose: http://somethingaboutorange.com/mrl/projects/nose/\n.. _nose plugins: http://nose-plugins.jottit.com/\n\n\nInstallation\n------------\n\nYou can get django-nose from PyPI with... ::\n\n    pip install django-nose\n\nThe development version can be installed with... ::\n\n    pip install -e git://github.com/jbalogh/django-nose.git#egg=django-nose\n\nSince django-nose extends Django's built-in test command, you should add it to\nyour ``INSTALLED_APPS`` in ``settings.py``::\n\n    INSTALLED_APPS = (\n        ...\n        'django_nose',\n        ...\n    )\n\nThen set ``TEST_RUNNER`` in ``settings.py``::\n\n    TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'\n\n\nUse\n---\n\nThe day-to-day use of django-nose is mostly transparent; just run ``./manage.py\ntest`` as usual.\n\nSee ``./manage.py help test`` for all the options nose provides, and look to\nthe `nose docs`_ for more help with nose.\n\n.. _nose docs: http://somethingaboutorange.com/mrl/projects/nose/\n\n\nEnabling Database Reuse\n-----------------------\n\nYou can save several seconds at the beginning and end of your test suite by\nreusing the test database from the last run. To do this, set the environment\nvariable ``REUSE_DB`` to 1::\n\n    REUSE_DB=1 ./manage.py test\n\nThe one new wrinkle is that, whenever your DB schema changes, you should leave\nthe flag off the next time you run tests. This will cue the test runner to\nreinitialize the test database.\n\nAlso, REUSE_DB is not compatible with TransactionTestCases that leave junk in\nthe DB, so be sure to make your TransactionTestCases hygienic (see below) if\nyou want to use it.\n\n\nEnabling Fast Fixtures\n----------------------\n\ndjango-nose includes a fixture bundler which drastically speeds up your tests\nby eliminating redundant setup of Django test fixtures. To use it...\n\n1. Subclass ``django_nose.FastFixtureTestCase`` instead of\n   ``django.test.TestCase``. (I like to import it ``as TestCase`` in my\n   project's ``tests/__init__.py`` and then import it from there into my actual\n   tests. Then it's easy to sub the base class in and out.) This alone will\n   cause fixtures to load once per class rather than once per test.\n2. Activate fixture bundling by passing the ``--with-fixture-bundling`` option\n   to ``./manage.py test``. This loads each unique set of fixtures only once,\n   even across class, module, and app boundaries.\n\nHow Fixture Bundling Works\n~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe fixture bundler reorders your test classes so that ones with identical sets\nof fixtures run adjacently. It then advises the first of each series to load\nthe fixtures once for all of them (and the remaining ones not to bother). It\nalso advises the last to tear them down. Depending on the size and repetition\nof your fixtures, you can expect a 25% to 50% speed increase.\n\nIncidentally, the author prefers to avoid Django fixtures, as they encourage\nirrelevant coupling between tests and make tests harder to comprehend and\nmodify. For future tests, it is better to use the \"model maker\" pattern,\ncreating DB objects programmatically. This way, tests avoid setup they don't\nneed, and there is a clearer tie between a test and the exact state it\nrequires. The fixture bundler is intended to make existing tests, which have\nalready committed to fixtures, more tolerable.\n\nTroubleshooting\n~~~~~~~~~~~~~~~\n\nIf using ``--with-fixture-bundling`` causes test failures, it likely indicates\nan order dependency between some of your tests. Here are the most frequent\nsources of state leakage we have encountered:\n\n* Locale activation, which is maintained in a threadlocal variable. Be sure to\n  reset your locale selection between tests.\n* memcached contents. Be sure to flush between tests. Many test superclasses do\n  this automatically.\n\nIt's also possible that you have ``post_save`` signal handlers which create\nadditional database rows while loading the fixtures. ``FastFixtureTestCase``\nisn't yet smart enough to notice this and clean up after it, so you'll have to\ngo back to plain old ``TestCase`` for now.\n\nExempting A Class From Bundling\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIn some unusual cases, it is desirable to exempt a test class from fixture\nbundling, forcing it to set up and tear down its fixtures at the class\nboundaries. For example, we might have a ``TestCase`` subclass which sets up\nsome state outside the DB in ``setUpClass`` and tears it down in\n``tearDownClass``, and it might not be possible to adapt those routines to heed\nthe advice of the fixture bundler. In such a case, simply set the\n``exempt_from_fixture_bundling`` attribute of the test class to ``True``.\n\n\nSpeedy Hygienic TransactionTestCases\n------------------------------------\n\nUnlike the stock Django test runner, django-nose lets you write custom\nTransactionTestCase subclasses which expect to start with an unmarred DB,\nsaving an entire DB flush per test.\n\nBackground\n~~~~~~~~~~\n\nThe default Django TransactionTestCase class `can leave the DB in an unclean\nstate`_ when it's done. To compensate, TransactionTestCase does a\ntime-consuming flush of the DB *before* each test to ensure it begins with a\nclean slate. Django's stock test runner then runs TransactionTestCases last so\nthey don't wreck the environment for better-behaved tests. django-nose\nreplicates this behavior.\n\nEscaping the Grime\n~~~~~~~~~~~~~~~~~~\n\nSome people, however, have made subclasses of TransactionTestCase that clean up\nafter themselves (and can do so efficiently, since they know what they've\nchanged). Like TestCase, these may assume they start with a clean DB. However,\nany TransactionTestCases that run before them and leave a mess could cause them\nto fail spuriously.\n\ndjango-nose offers to fix this. If you include a special attribute on your\nwell-behaved TransactionTestCase... ::\n\n    class MyNiceTestCase(TransactionTestCase):\n        cleans_up_after_itself = True\n\n...django-nose will run it before any of those nasty, trash-spewing test cases.\nYou can thus enjoy a big speed boost any time you make a TransactionTestCase\nclean up after itself: skipping a whole DB flush before every test. With a\nlarge schema, this can save minutes of IO.\n\ndjango-nose's own FastFixtureTestCase uses this feature, even though it\nultimately acts more like a TestCase than a TransactionTestCase.\n\n.. _can leave the DB in an unclean state: https://docs.djangoproject.com/en/1.4/topics/testing/#django.test.TransactionTestCase\n\n\nTest-Only Models\n----------------\n\nIf you have a model that is used only by tests (for example, to test an\nabstract model base class), you can put it in any file that's imported in the\ncourse of loading tests. For example, if the tests that need it are in\n``test_models.py``, you can put the model in there, too. django-nose will make\nsure its DB table gets created.\n\n\nAssertions\n----------\n\n``django-nose.tools`` provides pep8 versions of Django's TestCase asserts\nand some of its own as functions. ::\n\n   assert_redirects(response, expected_url, status_code=302, target_status_code=200, host=None, msg_prefix='')\n\n   assert_contains(response, text, count=None, status_code=200, msg_prefix='')\n   assert_not_contains(response, text, count=None, status_code=200, msg_prefix='')\n\n   assert_form_error(response, form, field, errors, msg_prefix='')\n\n   assert_template_used(response, template_name, msg_prefix='')\n   assert_template_not_used(response, template_name, msg_prefix='')\n\n   assert_queryset_equal(qs, values, transform=repr)\n\n   assert_num_queries(num, func=None, *args, **kwargs)\n\n   assert_code(response, status_code, msg_prefix='')\n\n   assert_ok(response, msg_prefix='')\n\n   assert_mail_count(count, msg=None)\n\n\nUsing With South\n----------------\n\n`South`_ installs its own test command that turns off migrations during\ntesting. Make sure that django-nose comes *after* ``south`` in\n``INSTALLED_APPS`` so that django_nose's test command is used.\n\n.. _South: http://south.aeracode.org/\n\n\nAlways Passing The Same Options\n-------------------------------\n\nTo always set the same command line options you can use a `nose.cfg or\nsetup.cfg`_ (as usual) or you can specify them in settings.py like this::\n\n    NOSE_ARGS = ['--failed', '--stop']\n\n.. _nose.cfg or setup.cfg: http://somethingaboutorange.com/mrl/projects/nose/0.11.2/usage.html#configuration\n\n\nCustom Plugins\n--------------\n\nIf you need to `make custom plugins`_, you can define each plugin class\nsomewhere within your app and load them from settings.py like this::\n\n    NOSE_PLUGINS = [\n        'yourapp.tests.plugins.SystematicDysfunctioner',\n        # ...\n    ]\n\nJust like middleware or anything else, each string must be a dot-separated,\nimportable path to an actual class. Each plugin class will be instantiated and\nadded to the Nose test runner.\n\n.. _make custom plugins: http://somethingaboutorange.com/mrl/projects/nose/0.11.2/plugins.html#writing-plugins\n\n\nOlder Versions of Django\n------------------------\nUpgrading from Django \u003c= 1.3 to Django 1.4\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nIn versions of Django \u003c 1.4 the project folder was in fact a python package as\nwell (note the __init__.py in your project root). In Django 1.4, there is no\nsuch file and thus the project is not a python module.\n\n**When you upgrade your Django project to the Django 1.4 layout, you need to\nremove the __init__.py file in the root of your project (and move any python\nfiles that reside there other than the manage.py) otherwise you will get a\n`ImportError: No module named urls` exception.**\n\nThis happens because Nose will intelligently try to populate your sys.path, and\nin this particular case includes your parent directory if your project has a\n__init__.py file (see: https://github.com/nose-devs/nose/blob/release_1.1.2/nose/importer.py#L134).\n\nThis means that even though you have set up your directory structure properly and\nset your `ROOT_URLCONF='my_project.urls'` to match the new structure, when running\ndjango-nose's test runner it will try to find your urls.py file in `'my_project.my_project.urls'`.\n\n\n\n\nUpgrading from Django \u003c 1.2\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDjango 1.2 switches to a `class-based test runner`_. To use django-nose\nwith Django 1.2, change your ``TEST_RUNNER`` from ``django_nose.run_tests`` to\n``django_nose.NoseTestSuiteRunner``.\n\n``django_nose.run_tests`` will continue to work in Django 1.2 but will raise a\nwarning. In Django 1.3, it will stop working.\n\nIf you were using ``django_nose.run_gis_tests``, you should also switch to\n``django_nose.NoseTestSuiteRunner`` and use one of the `spatial backends`_ in\nyour ``DATABASES`` settings.\n\n.. _class-based test runner: http://docs.djangoproject.com/en/dev/releases/1.2/#function-based-test-runners\n.. _spatial backends: http://docs.djangoproject.com/en/dev/ref/contrib/gis/db-api/#id1\n\nDjango 1.1\n~~~~~~~~~~\n\nIf you want to use django-nose with Django 1.1, use\nhttps://github.com/jbalogh/django-nose/tree/django-1.1 or\nhttp://pypi.python.org/pypi/django-nose/0.0.3.\n\nDjango 1.0\n~~~~~~~~~~\n\ndjango-nose does not support Django 1.0.\n\n\nRecent Version History\n----------------------\n\n1.1 (2012-05-19)\n  * Django TransactionTestCases don't clean up after themselves; they leave\n    junk in the DB and clean it up only on ``_pre_setup``. Thus, Django makes\n    sure these tests run last. Now django-nose does, too. This means one fewer\n    source of failures on existing projects. (Erik Rose)\n  * Add support for hygienic TransactionTestCases. (Erik Rose)\n  * Support models that are used only for tests. Just put them in any file\n    imported in the course of loading tests. No more crazy hacks necessary.\n    (Erik Rose)\n  * Make the fixture bundler more conservative, fixing some conceivable\n    situations in which fixtures would not appear as intended if a\n    TransactionTestCase found its way into the middle of a bundle. (Erik Rose)\n  * Fix an error that would surface when using SQLAlchemy with connection\n    pooling. (Roger Hu)\n  * Gracefully ignore the new ``--liveserver`` option introduced in Django 1.4;\n    don't let it through to nose. (Adam DePue)\n\n1.0 (2012-03-12)\n  * New fixture-bundling plugin for avoiding needless fixture setup (Erik Rose)\n  * Moved FastFixtureTestCase in from test-utils, so now all the\n    fixture-bundling stuff is in one library. (Erik Rose)\n  * Added the REUSE_DB setting for faster startup and shutdown. (Erik Rose)\n  * Fixed a crash when printing options with certain verbosities. (Daniel Abel)\n  * Broke hard dependency on MySQL. Support PostgreSQL. (Roger Hu)\n  * Support SQLite, both memory- and disk-based. (Roger Hu and Erik Rose)\n  * Nail down versions of the package requirements. (Daniel Mizyrycki)\n\n0.1.3 (2010-04-15)\n  * Even better coverage support (rozza)\n  * README fixes (carljm and ionelmc)\n  * optparse OptionGroups are handled better (outofculture)\n  * nose plugins are loaded before listing options\n\nSee more in changelog.txt.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffabiosantoscode%2Fdjango-nose-123-fix","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffabiosantoscode%2Fdjango-nose-123-fix","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffabiosantoscode%2Fdjango-nose-123-fix/lists"}