Unit testing Django model mixins
This facilitates unit tests for model mixins in Django. For more info, see [my blog](https://michael.mior.ca/blog/unit-testing-django-model-mixins/).
- models
- testing
- mixin
Snippet List
Testing for pending migrations in Django
DB migration support has been added in Django 1.7+, superseding South. More specifically, it's possible to automatically generate migrations steps when one or more changes in the application models are detected. Definitely a nice feature! I've written a small generic unit-test that one should be able to drop into the tests directory of any Django project and that checks there's no pending migrations, ie. if the models are correctly in sync with the migrations declared in the application. Handy to check nobody has forgotten to git add the migration file or that an innocent looking change in models.py doesn't need a migration step generated. Enjoy!
- testing
- unittest
- database
- migration
Test Django against many Pythons and databases
I'm posting this here mostly because I need a more permanent home for this than my lappy's hard drive. I hope it's interesting to other people, though. Anyway - this script is what I use to test Django against multiple versions of Python and multiple databases. To actually run this you'll of course need Python 2.3, 2.4, and 2.5 installed along with MySQL, PostgreSQL, and sqlite3 -- and the associated database wrappers for all 3 Pythons. Yes, for the record, I've got all those things installed on my laptop. If you can somehow make that work, though, running this script will print out a nice little summary of what's failing against which versions of Python and which database. Run with `-v` to see the actual failures.
- testing
Testing (and mocking) http requests to APIs etc.
You can test how your django app behaves depending on what kind of response it gets from the API. It assumes were're using the python requests library.
- http
- testing
- requests
- mock
Testing email sending
How I assert email is being sent correctly
- testing
Add Extra Headers to Test Client Requests
As Simon Willison mentions in his [Debugging Django](http://simonwillison.net/2008/May/22/debugging/) presentation, using the Test Client in the interpreter can be a great way to take a peek at the raw results from a view. In some cases you may need to add additional headers to the request (for instance a piece of middleware may rely on them). Though it is not mentioned in the reference documentation, a quick peek at the code confirmed my hopes that it would be possible to add data to the request. The Client *get* and *post* methods both accept an **extra** kwargs parameter that allow you to populate the request with additional data.
- testing
- request
- test
- headers
Syntax highlighting for tracebacks in console output
This is hardcoded to use [django-discover-runner](http://pypi.python.org/pypi/django-discover-runner) since that's my main test runner but could easily be adopted to use Django's own test runner. If you're using a terminal that is capable of showing 256 colors use the `Terminal256Formatter` formatter instead. Enabled it with the `TEST_RUNNER` setting: TEST_RUNNER = 'dotted.path.to.highlighted.runner.HighlightedDiscoverRunner' Where `dotted.path.to.highlighted.runner` is the Python import path of the file you saved the runner in.
- pygments
- testing
- test
- traceback
RequestFactory: Easily create mock request objects, for use in testing
Django's testing framework assumes you will be running your tests against "live" views that have been plugged in to your site's URL configuration - but sometimes you might want to run a test against a view function without first wiring it in to the rest of the site. This class makes it easy to do that by providing a "factory" for creating mock request objects, re-using the existing test Client interface (and most of the code). Once you've created a request object in your test you can use it to call your view functions directly, then run assertions against the response object that gets returned.
- testing
- httprequest
Fixture for test users
This is a simple fixture that is useful for many tests. It contains the following users: * admin * staff * user0 * user1 * user2 * user3 * inactive0 * inactive1 The password of every user is the same as his username, e.g.: admin/admin
- testing
- fixtures
- auth
- test
- fixture
- users
Run a testcase with custom INSTALLED_APPS
This code allows you to register a model to Django that is only used for unit testing. It will not exist in the regular Django workflow. After the tests executed, the Django settings are restored. Usage: 1. Change `tests.py` into a `tests` package. 2. Place a `models.py` in the `tests` package. 3. Use the following code below to enable it. Example: class MyTest(CustomSettingsTestCase): new_settings = dict( INSTALLED_APPS=( 'django.contrib.contenttypes', 'django.contrib.auth', 'app_to_test', 'app_to_test.tests', ) ) Based on http://djangosnippets.org/snippets/1011/ as Django 1.4 version
- settings
- testing
- test
- syncdb
Test runner that installs 'tests' packages as apps
Ever tried to unit test custom fields or abstract models? If so, you probably used a solution like [this one](http://djangosnippets.org/snippets/2843/). It surely works, but it has some issues: 1. Runs 'syncdb' several times. 2. It's not automatic. You must add the mixin or copy the code to each of the TestCases. This test runner adds to INSTALLED_APPS the 'app.tests' package for **each of the specified** apps, **before the 'syncdb' happens**. This has the [discovery runner](https://pypi.python.org/pypi/django-discover-runner) as a dependency (for 1.5 only, it will be the default in 1.6). However, it comes as a mixin so it should be easily pluggable to other test runners. If you intend to use the mixin with other runners, note that it imports 'app.tests.models' so it won't work with tests modules (tests.py). Your runner must "use" test packages (like discovery runner). # USAGE # in your settings.py: TESTAPPS_INSTALL = ( 'app1', 'app2', # ... ) TEST_RUNNER = 'testapp_runner.DiscoverTestAppRunner' # example import path # extra apps in command line. # run test for apps 'app1' to 'app4', adding 'app3' and 'app4' to the TESTAPPS_INSTALL setting. manage.py test app1 app2 app3 app4 --with-test-app=app3 --with-test-app=app4
- django
- testing
- apps
- testrunner
- test-runner
- app-models
Exclude Apps When Testing
This allows you to exclude certain apps when doing standard tests (manage.py test) by default. You set the settings/local_settings variable EXCLUDE_APPS and it will exclude those apps (like django, registration, south... etc). This makes running tests much faster and you don't have to wait for a bunch of tests you don't care about (per say). You can override it by adding the app to the command line still. So if 'south' is in the excluded apps you can still run: 'python manage.py test south' and it will run the south tests. You will also need to tell django to use this as the test runner: TEST_RUNNER = 'testing.simple.AdvancedTestSuiteRunner'
- testing
- tests
- exclude
Django and Twill
Django's test client is very limited when it comes to testing complex interactions e.g. forms with hidden or persisted values etc. Twill excels in this area, and thankfully it is very easy to integrate it. * Use `twill_setup` in your `TestCaseSubClass.setUp()` method * Use `twill_teardown` in `TestCaseSubClass.tearDown()` method * In a test, use something like `make_twill_url()` to generate URLs that will work for twill. * Use `twill.commands.go()` etc. to control twill, or use `twill.execute_string()` or `twill.execute_script()`. * Add `twill.set_output(StringIO())` to suppress twill output * If you want to write half the test, then use twill interactively to write the rest as a twill script, use the example in `unfinished_test()` Twill will raise exceptions if commands fail. This means you will get 'E' for error, rather than 'F' for fail in the test output. If necessary, it wouldn't be hard to wrap the twill commands to flag failure with TestCase.assert_ There are, of course, more advanced ways of using these functions (e.g. a mixin that does the setup/teardown for you), but the basic functions needed are here. See also: * [Twill](http://twill.idyll.org/) * [Twill Python API](http://twill.idyll.org/python-api.html)
- testing
- tests
- twill
send_mail wrapper with DEBUG email trapping
By using this simple wrapper instead of Django's default send_mail function, you gain the peace of mind of knowing that when settings.DEBUG == True, all the emails will be sent to you instead of the original recipient. Handy for testing.
- debug
- testing
- intercept
- trap
local django model test
Sometimes you need to test some model features without a complete django app installation. Just play only with the model object. With these small script you have a complete in memory django installation. Some Links: http://www.djangosnippets.org/snippets/1044/ (en) http://www.jensdiemer.de/permalink/150/mein-blog/99/django-db-model-test/ (de) http://www.python-forum.de/viewtopic.php?f=3&t=15649 (de) See also: https://github.com/readevalprint/mini-django/
- model
- testing
- test
- local-test