Login

Tag "test"

29 snippets

Snippet List

TestSettingsManager: temporarily change settings for tests

This TestSettingsManager class takes some of the pain out of making temporary changes to settings for the purposes of a unittest or doctest. It will keep track of the original settings and let you easily revert them back when you're done. It also handles re-syncing the DB if you modify INSTALLED_APPS, which is especially handy if you have some test-only models in tests/models.py. This makes it easy to dynamically get those models synced to the DB before running your tests. Sample doctest usage, for testing an app called "app_under_test," that has a tests/ sub-module containing a urls.py for testing URLs, a models.py with some testing models, and a templates/ directory with test templates: >>> from test_utils import TestManager; mgr = TestManager() >>> import os >>> mgr.set(INSTALLED_APPS=('django.contrib.contenttypes', ... 'django.contrib.sessions', ... 'django.contrib.auth', ... 'app_under_test', ... 'app_under_test.tests'), ... ROOT_URLCONF='app_under_test.tests.urls', ... TEMPLATE_DIRS=(os.path.join(os.path.dirname(__file__), ... 'templates'),)) ...do your doctests... >>> mgr.revert()

  • settings
  • test
  • syncdb
Read More

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
Read More

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
Read More

Automatic testing of add and changelist admin views

If you want to test for trivial error in your add and changelist admin views, use this snippet. Save the snippet in admintests.py and put it anywhere in your pythonpath. Put this code in your tests.py: from django.test import TestCase from admintest import adminviews_test class TestAdminViews(TestCase): def test_admin_views(self): adminviews_test(self)

  • admin
  • test
  • automatic test
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
Read More
Author: V
  • 3
  • 3

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
Read More

Dynamic Test Loading

Ok... this is really a hack. But I love it. I hate setting up all of my test cases into suites, and making sure that I remember to add them each time I add a new python file... annoying! This allows me to have a tests package and then just add python files and packages to that test package (mirroring my app setup). Each of the files are then dynamically imported and every test case is automatically executed. If you don't want one to execute, add it to the ignore list. If you add 'views' to the ignore list, it will ignore all views, otherwise you would have to specify 'package.views' if it is in a package. So... in short this is a bit ghetto, but it saves me a lot of time just setting up all my tests... now I can just write them! Hope it's useful to someone. Greg

  • dynamic
  • unittest
  • load
  • test
  • loader
  • loading
  • unit
Read More

Load customized SQL

A management.py loading customized SQL feeding it raw to the database backend. Just put it as `management.py` in your app and put whatever SQL you want run after syncdb in `app/sql/custom.backend_driver.sql`. If the `backend_driver` is skipped the SQL will be loaded no matter database backend. Since it is run after syncdb it will also be run for test.

  • sql
  • test
  • "initial
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
Read More

Fake SSL Middleware for Tests and Local Development

Add `FakeSSLMiddleware` to the top of your `MIDDLEWARE_CLASSES` stack when running tests or developing locally to allow https:// links to operate correctly. Can be used in conjunction with other SSL middleware to allow critical tests to be performed.

  • middleware
  • ssl
  • testing
  • test
  • https
  • local
  • fake
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
Read More

Test Server Thread

This class runs a django test server in another thread. This is very useful for e.g. selenium integration. Simple to integrate into django test framework. Usage: server = TestServerThread("127.0.0.1", "8081") server.start() # Run tests e.g. req = urllib.urlopen("http://127.0.0.1:8081") contents = req.read() server.stop() ps. I don't actually double space my code :). Not sure whats up with that!

  • thread
  • test
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
Read More