diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/howto/index.txt | 1 | ||||
| -rw-r--r-- | docs/howto/windmill-tests.txt | 58 | ||||
| -rw-r--r-- | docs/index.txt | 4 | ||||
| -rw-r--r-- | docs/topics/testing.txt | 118 |
4 files changed, 177 insertions, 4 deletions
diff --git a/docs/howto/index.txt b/docs/howto/index.txt index 1a27a2ebac..214f36e47f 100644 --- a/docs/howto/index.txt +++ b/docs/howto/index.txt @@ -25,6 +25,7 @@ you quickly accomplish common tasks. outputting-csv outputting-pdf static-files + windmill-tests .. seealso:: diff --git a/docs/howto/windmill-tests.txt b/docs/howto/windmill-tests.txt new file mode 100644 index 0000000000..3321bb1869 --- /dev/null +++ b/docs/howto/windmill-tests.txt @@ -0,0 +1,58 @@ +.. _howto-windmill-tests: + +Writing a Functional Tests with Windmill +======================================== + +.. currentmodule:: django.test + +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: + +.. _Windmill: http://getwindmill.com + +#. Your windmill tests must be their own module, named ``wmtests`` or ``windmilltests``. + +#. 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 + + def test_loginAndSetup(): + '''Mostly just a proof of concept to test working order of tests.''' + client = WindmillTestClient(calling_func_name()) + + client.open(url='http://localhost:8000/admin') + client.waits.forPageLoad(timeout=u'20000') + ... + +#. Your windmill testing module must load any files other than the module loader in ``__init__.py``.:: + + from primary import * + ... + +Setup and Teardown are done differently for windmill tests, and consist of the following +functions. : + + * :meth:`setup_module` + * :meth:`teardown_module` + +A sample implementation, in ``__init__.py``.:: + + from primary import * + + def setup_module(module): + module.property = fetch_property() + + def teardown_module(module): + module.property = None + + + +These methods can be included in any file with windmill tests. See `functest`_ +for more information. + +.. _functest : http://functest.pythonesque.org/
\ No newline at end of file diff --git a/docs/index.txt b/docs/index.txt index d03f90c117..03478f06a2 100644 --- a/docs/index.txt +++ b/docs/index.txt @@ -142,7 +142,9 @@ The development process :ref:`Overview <ref-django-admin>` | :ref:`Adding custom commands <howto-custom-management-commands>` - * **Testing:** :ref:`Overview <topics-testing>` + * **Testing:** + :ref:`Overview <topics-testing>` | + :ref:`Windmill <howto-windmill-tests>` * **Deployment:** :ref:`Overview <howto-deployment-index>` | diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt index cec6002b7b..d066ca086a 100644 --- a/docs/topics/testing.txt +++ b/docs/topics/testing.txt @@ -400,7 +400,7 @@ Some of the things you can do with the test client are: a template context that contains certain values. Note that the test client is not intended to be a replacement for Twill_, -Selenium_, or other "in-browser" frameworks. Django's test client has +Windmill_, or other "in-browser" frameworks. Django's test client has a different focus. In short: * Use Django's test client to establish that the correct view is being @@ -409,10 +409,15 @@ a different focus. In short: * Use in-browser frameworks such as Twill and Selenium to test *rendered* HTML and the *behavior* of Web pages, namely JavaScript functionality. -A comprehensive test suite should use a combination of both test types. +A comprehensive test suite should use a combination of both test types. Which +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-tests>` .. _Twill: http://twill.idyll.org/ -.. _Selenium: http://www.openqa.org/selenium/ +.. _Windmill: http://www.getwindmill.com/ Overview and a quick example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -706,6 +711,28 @@ arguments at time of construction: and session data cleared to defaults. Subsequent requests will appear to come from an AnonymousUser. + +Making mock requests +~~~~~~~~~~~~~~~~~~~~ +.. versionadded:: 1.1 + +Use the ``django.test.mocks.RequestFactory`` class to create mock requests. Usage is as follows. +:: + rf = RequestFactory() + get_request = rf.get('/hello/') + post_request = rf.post('/submit/', {'foo': 'bar'}) + +Once you have a request object you can pass it to any view function, just as if + that view had been hooked up using a URLconf. + + +.. class:: RequestFactory() + There is only one method on a ``RequestFactory``. + + .. method:: RequestFactory.request(path, **request) + This will return a request object with the proper environment. + + Testing responses ~~~~~~~~~~~~~~~~~ @@ -938,6 +965,8 @@ This means, instead of instantiating a ``Client`` in each test:: response = self.client.get('/customer/index/') self.failUnlessEqual(response.status_code, 200) + + .. _topics-testing-fixtures: Fixture loading @@ -999,6 +1028,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 ~~~~~~~~~~~~~~~~~~~~~ @@ -1032,6 +1063,87 @@ 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``. + +Skipping tests bound to fail +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. versionadded: 1.1 + +Occasionally it's helpful to specify tests that are skipped under certain +circumstances. To accomplish this, the Django test framework offers decorators +that you can apply to your test methods for them to be conditionally skipped. + +You can supply your own condition function as follows:: + + from django.tests.decorators import * + + class TestUnderCondition(TestCase): + + def _my_condition(): + # Condition returning True if test should be run and False if it + # should be skipped. + + @conditional_skip(_my_condition, reason='This test should be skipped sometimes') + def testOnlyOnTuesday(self): + # Test to run if _my_condition evaluates to True + +In addition, the Django test framework supplies a handful of skip conditions that +handle commonly used conditions for skipping tests. + +``views_required(required_views=[])`` + Does a ``urlresolver.Reverse`` on the required views supplied. Runs test only if + all views in ``required_views`` are in use. + +``modules_required(required_modules=[])`` + Runs tests only if all modules in ``required_modules`` can be imported. + +``skip_specific_database(database_engine)`` + Skips test if ``settings.DATABASE_ENGINE`` is equal to database_engine. + +If a test is skipped, it is added to a skipped category in the test runner and +the test results are reported as such:: + + ====================================================================== + SKIPPED: test_email_found (django.contrib.auth.tests.basic.PasswordResetTest) + ---------------------------------------------------------------------- + Traceback (most recent call last): + File "/Users/dnaquin/Dropbox/Sandbox/django/django/test/decorators.py", line 43, in _skip + raise SkippedTest(reason=reason) + SkippedTest: Required view for this test not found: django.contrib.auth.views.password_reset + + ---------------------------------------------------------------------- + Ran 408 tests in 339.663s + + FAILED (failures=1, skipped=2) + .. _emptying-test-outbox: Emptying the test outbox |