4 files changed, 82 insertions, 4 deletions
diff --git a/docs/howto/static-files/index.txt b/docs/howto/static-files/index.txt
index db8bd38e9c..b423119916 100644
--- a/docs/howto/static-files/index.txt
+++ b/docs/howto/static-files/index.txt
@@ -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
 ==========
 
diff --git a/docs/ref/contrib/staticfiles.txt b/docs/ref/contrib/staticfiles.txt
index b9963414f4..8f5c1b25d1 100644
--- a/docs/ref/contrib/staticfiles.txt
+++ b/docs/ref/contrib/staticfiles.txt
@@ -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`.
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 3c478c249a..10826829a8 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -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
 ==========================
 
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 89b38f7573..d7af823038 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -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
+
+    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.
 
-    ``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`).
+    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::