diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/howto/windmill-tests.txt | 50 | ||||
| -rw-r--r-- | docs/topics/testing.txt | 33 |
2 files changed, 56 insertions, 27 deletions
diff --git a/docs/howto/windmill-tests.txt b/docs/howto/windmill-tests.txt index 08931d8a97..5445dc4de9 100644 --- a/docs/howto/windmill-tests.txt +++ b/docs/howto/windmill-tests.txt @@ -1,40 +1,38 @@ .. _howto-windmill-tests: Writing a Functional Tests with Windmill -======================================= +======================================== .. currentmodule:: django.test -If you need to provide custom file storage -- a common example is storing files -on some remote system -- you can do so by defining a custom storage class. -You'll need to follow these steps: +If you need to test overall behaviors of your site, ajax widgets or rendered +html, then functional tests are the solution. Django includes support for the +popular `Windmill`_ framework. Writing a windmill test +is simple, following these steps: -#. Your custom storage system must be a subclass of - ``django.core.files.storage.Storage``:: +.. _Windmill: http://getwindmill.com +#. Your windmill tests must be their own module, named ``wmtests`` or ``windmilltests``. + - from django.core.files.storage import Storage +#. Django must be able to run any function in the module without arguments. +:: + from windmill.conf import global_settings + ADMIN_URL = "%s/test_admin/admin" % global_settings.TEST_URL + from windmill.authoring import WindmillTestClient + from django.test.utils import calling_func_name - class MyStorage(Storage): - ... + def test_loginAndSetup(): + '''Mostly just a proof of concept to test working order of tests.''' + client = WindmillTestClient(calling_func_name()) -#. Django must be able to instantiate your storage system without any arguments. - This means that any settings should be taken from ``django.conf.settings``:: + client.open(url='http://localhost:8000/admin') + client.waits.forPageLoad(timeout=u'20000') + ... - from django.conf import settings - from django.core.files.storage import Storage - - class MyStorage(Storage): - def __init__(self, option=None): - if not option: - option = settings.CUSTOM_STORAGE_OPTIONS - ... - -#. Your storage class must implement the ``_open()`` and ``_save()`` methods, - along with any other methods appropriate to your storage class. See below for - more on these methods. - - In addition, if your class provides local file storage, it must override - the ``path()`` method. +#. Your windmill testing module must load any files other than the module loader + in ``__init__.py``. + :: + from primary.py import * Your custom storage system may override any of the storage methods explained in :ref:`ref-files-storage`, but you **must** implement the following methods: diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt index 2a01df9e87..d4e1eb8eaf 100644 --- a/docs/topics/testing.txt +++ b/docs/topics/testing.txt @@ -414,7 +414,7 @@ is why Django makes it easy to integrate with 3rd party test runners via the :setting:`TEST_RUNNER` setting. For convenience, Django ships a runner for the framework used in testing the :ref:`admin interface, <ref-contrib-admin>` Windmill_. Details on integrating Windmill tests with Django are available -:ref:`here. <howto-windmill-test>` +:ref:`here. <howto-windmill-tests>` .. _Twill: http://twill.idyll.org/ .. _Windmill: http://www.getwindmill.com/ @@ -981,6 +981,8 @@ This flush/load procedure is repeated for each test in the test case, so you can be certain that the outcome of a test will not be affected by another test, or by the order of test execution. +.. _topics-testing-urlconf: + URLconf configuration ~~~~~~~~~~~~~~~~~~~~~ @@ -1014,6 +1016,35 @@ For example:: This test case will use the contents of ``myapp.test_urls`` as the URLconf for the duration of the test case. +.. _topics-testing-testmodels: + +Test-Only Models configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. versionadded:: 1.1 + +.. attribute:: TransactionTestCase.test_models + +If you want to test your application with models that are only available during specific +test cases, ``django.test.TransactionTestCase`` provides the ability to customize the models +configuration for the duration of the execution of a test suite. If your +``TransactionTestCase`` instance defines an ``test_models`` attribute, the ``TransactionTestCase`` will load +the value of that attribute as a module, and load the models contained within for the +duration of that test. + +For example:: + + from django.test import TransactionTestCase + + class TestMyViews(TransactionTestCase): + test_models = ['test_models'] + + def testIndexPageView(self): + # Here you'd test your view using ``Client``. + +This test case will load the contents of ``myapp.test_models`` and add +any subclass of ``django.db.models.Model`` to ``myapp.models``. + .. _emptying-test-outbox: Emptying the test outbox |