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

Mon 01 Sep 2014 Read More

TestCase helpers

I use these helper methods in my unit tests. They turn many simple getting-and-posting tests into one-liners. Definitely a work in progress, and I can't be the only person who has done this sort of thing -- comments are more than welcome.

• testing
• tests
• unittest

Sat 13 Nov 2010 Read More

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

Sun 14 Jun 2015 Read More

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

Mon 24 Dec 2012 Read More

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

Mon 23 Sep 2013 Read More

assertQuerysetEqual

I often find myself testing that the queryset returned by a method contains the instances I expect. I use a custom method, **assertQuerysetEqual()**, to test the equality of two querysets or lists:: def test_some_values(self): qs = get_user_list() self.assertQuerysetEqual(qs, [normal_user, super_user]) Makes it easy to test small querysets against lists whose values are known and expected.

• testing
• test

Mon 30 Jan 2012 Read More

Breaking tests.py into multiple files

Django loads tests found in models.py and tests.py (if present) or actually a module or package named 'tests' under the app. Since tests can be a package, one can create a 'tests' directory, split the test cases across multiple files under 'tests' and import them from tests/__init__.py with: # tests/__init__.py from test_mod1 import * from test_mod2 import * ... from test_modN import * For a small number of files that's not too bad but it gets old as more files are added, plus it is error prone (e.g. test cases shadowing others with the same name). The snippet above simplifies the test splitting without importing everything into the same namespace. Typical usage: # tests/__init__.py from ... import get_suite suite = lambda: get_suite(__name__)

• testing
• tests
• test

Thu 14 Jul 2011 Read More

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

Thu 10 May 2012 Read More

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

Thu 26 Jun 2014 Read More

Stop tests at the first failure

**Note**: The `--failfast` argument in Django since version 1.2 does this. Use this snippet for earlier versions. If a large number of your unit tests get "out of sync", it's often annoying to scan through a large number of test failures which overflow the terminal window's scroll buffer. This library strictly stops after the first failure in a doctest suite. If you're testing multiple applications, it also stops after the first test suite with failures in it. So effectively you'll get one failure at a time. This code has been tested with doctests only so far. You can also fetch the latest source from [my repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/test/).

• testing
• unittest

Thu 19 Aug 2010 Read More

Test Suite URL Coverage

This custom test suite runner will record all of the URLs accessed during your test suite. It will compare it to the list of all URLs you have configured for your site and produce a report of any URLs missed. It requires that all URLs are named (using the ``name=`` parameter). To use is, set the ``TEST_RUNNER`` variable in your configuration to this class. You can also define ignored URLs. For example, to filter out the admin URLs, you can use: IGNORED_COVERAGE_URLS = ['^admin/', '^admin/doc/']

• urlconf
• testing
• testrunner

Mon 05 Mar 2012 Read More

Modify requests in your unit tests (improvement on RequestFactory)

This is an update to Simon Willison's snippet http://djangosnippets.org/snippets/963/, along with one of the comments in that snippet. This class lets you create a Request object that's gone through all the middleware. Suitable for unit testing when you need to modify something on the request directly, or pass in a mock object. (note: see http://labix.org/mocker for details on how to mock requests for testing) Example on how to use: from django.test import TestCase from yourapp import your_view from yourutils import RequestFactory class YourTestClass(TestCase): def setUp(self): pass def tearDown(self): pass # Create your own request, which you can modify, instead of using self.client. def test_your_view(self): # Create your request object rf = RequestFactory() request = rf.get('/your-url-here/') # ... modify the request to your liking ... response = your_view(request) self.assertEqual(response.status_code, 200) Suggestions/improvements are welcome. :)

• testing
• request
• client
• testcase

Mon 01 Nov 2010 Read More

HTML to POST dict converter

If you want to test a post request to a form, you need to give all input fields, even if you just want to test if one value gets changed. This snippets parses the HTML of a view and gives you a dictionary that you can give to django.test.Client.

• testing

Sun 11 Jul 2010 Read More

Db Mock

I hate when my unittest hits database. Especially when each test case needs different dataset. So I wrote this db mock, that's local to specific test and uses sqlite3 in-memory db. Usage (nosetests): class TestMainNoData(DbMock): 'testing main function with no meaningful data' def test_no_posts(self): 'there are no posts' assert models.Post.objects.count() == 0, 'should be no feeds'

• testing
• unittest
• database
• test

Thu 30 Sep 2010 Read More

local django test

Sometimes I would like to test a codesnippet without a complete django environment. Here is a small "local test script" you can use for this ;)

• testing
• test
• local-test

Sun 11 Jul 2010 Read More