mirror of
https://github.com/django/django.git
synced 2025-08-04 02:48:35 +00:00
Made django.test.testcases not depend on staticfiles contrib app.
Do this by introducing a django.contrib.staticfiles.testing.StaticLiveServerCase unittest TestCase subclass. Fixes #20739.
This commit is contained in:
parent
e0643cb676
commit
e909ceae9b
9 changed files with 285 additions and 32 deletions
|
@ -100,6 +100,33 @@ this by adding the following snippet to your urls.py::
|
|||
the given prefix is local (e.g. ``/static/``) and not a URL (e.g.
|
||||
``http://static.example.com/``).
|
||||
|
||||
.. _staticfiles-testing-support:
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
When running tests that use actual HTTP requests instead of the built-in
|
||||
testing client (i.e. when using the built-in :class:`LiveServerTestCase
|
||||
<django.test.LiveServerTestCase>`) the static assets need to be served along
|
||||
the rest of the content so the test environment reproduces the real one as
|
||||
faithfully as possible, but ``LiveServerTestCase`` has only very basic static
|
||||
file-serving functionality: It doesn't know about the finders feature of the
|
||||
``staticfiles`` application and assumes the static content has already been
|
||||
collected under :setting:`STATIC_ROOT`.
|
||||
|
||||
Because of this, ``staticfiles`` ships its own
|
||||
:class:`django.contrib.staticfiles.testing.StaticLiveServerCase`, a subclass
|
||||
of the built-in one that has the ability to transparently serve all the assets
|
||||
during execution of these tests in a way very similar to what we get at
|
||||
development time with ``DEBUG = True``, i.e. without having to collect them
|
||||
using :djadmin:`collectstatic` first.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
:class:`django.contrib.staticfiles.testing.StaticLiveServerCase` is new in
|
||||
Django 1.7. Previously its functionality was provided by
|
||||
:class:`django.test.LiveServerTestCase`.
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
|
|
|
@ -406,3 +406,26 @@ files in app directories.
|
|||
That's because this view is **grossly inefficient** and probably
|
||||
**insecure**. This is only intended for local development, and should
|
||||
**never be used in production**.
|
||||
|
||||
Specialized test case to support 'live testing'
|
||||
-----------------------------------------------
|
||||
|
||||
.. class:: testing.StaticLiveServerCase
|
||||
|
||||
This unittest TestCase subclass extends :class:`django.test.LiveServerTestCase`.
|
||||
|
||||
Just like its parent, you can use it to write tests that involve running the
|
||||
code under test and consuming it with testing tools through HTTP (e.g. Selenium,
|
||||
PhantomJS, etc.), because of which it's needed that the static assets are also
|
||||
published.
|
||||
|
||||
But given the fact that it makes use of the
|
||||
:func:`django.contrib.staticfiles.views.serve` view described above, it can
|
||||
transparently overlay at test execution-time the assets provided by the
|
||||
``staticfiles`` finders. This means you don't need to run
|
||||
:djadmin:`collectstatic` before or as a part of your tests setup.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
``StaticLiveServerCase`` is new in Django 1.7. Previously its functionality
|
||||
was provided by :class:`django.test.LiveServerTestCase`.
|
||||
|
|
|
@ -332,6 +332,20 @@ Miscellaneous
|
|||
Define a ``get_absolute_url()`` method on your own custom user object or use
|
||||
:setting:`ABSOLUTE_URL_OVERRIDES` if you want a URL for your user.
|
||||
|
||||
* The static asset-serving functionality of the
|
||||
:class:`django.test.LiveServerTestCase` class has been simplified: Now it's
|
||||
only able to serve content already present in :setting:`STATIC_ROOT` when
|
||||
tests are run. The ability to transparently serve all the static assets
|
||||
(similarly to what one gets with :setting:`DEBUG = True <DEBUG>` at
|
||||
development-time) has been moved to a new class that lives in the
|
||||
``staticfiles`` application (the one actually in charge of such feature):
|
||||
:class:`django.contrib.staticfiles.testing.StaticLiveServerCase`. In other
|
||||
words, ``LiveServerTestCase`` itself is less powerful but at the same time
|
||||
has less magic.
|
||||
|
||||
Rationale behind this is removal of dependency of non-contrib code on
|
||||
contrib applications.
|
||||
|
||||
Features deprecated in 1.7
|
||||
==========================
|
||||
|
||||
|
|
|
@ -1041,11 +1041,25 @@ out the `full reference`_ for more details.
|
|||
.. _full reference: http://selenium-python.readthedocs.org/en/latest/api.html
|
||||
.. _Firefox: http://www.mozilla.com/firefox/
|
||||
|
||||
.. note::
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``LiveServerTestCase`` makes use of the :doc:`staticfiles contrib app
|
||||
</howto/static-files/index>` so you'll need to have your project configured
|
||||
accordingly (in particular by setting :setting:`STATIC_URL`).
|
||||
Before Django 1.7 ``LiveServerTestCase`` used to rely on the
|
||||
:doc:`staticfiles contrib app </howto/static-files/index>` to get the
|
||||
static assets of the application(s) under test transparently served at their
|
||||
expected locations during the execution of these tests.
|
||||
|
||||
In Django 1.7 this dependency of core functionality on a ``contrib``
|
||||
appplication has been removed, because of which ``LiveServerTestCase``
|
||||
ability in this respect has been retrofitted to simply publish the contents
|
||||
of the file system under :setting:`STATIC_ROOT` at the :setting:`STATIC_URL`
|
||||
URL.
|
||||
|
||||
If you use the ``staticfiles`` app in your project and need to perform live
|
||||
testing then you might want to consider using the
|
||||
:class:`~django.contrib.staticfiles.testing.StaticLiveServerCase` subclass
|
||||
shipped with it instead because it's the one that implements the original
|
||||
behavior now. See :ref:`the relevant documentation
|
||||
<staticfiles-testing-support>` for more details.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue