From 1b236048b9a915296dc13081fad7bb75d0ff1f4d Mon Sep 17 00:00:00 2001
From: Kevin Christopher Henry <k@severian.com>
Date: Thu, 22 Aug 2013 04:39:31 -0400
Subject: [PATCH] [1.5.x] Documentation -- Clarified use of 'view' in test
 client introduction.

Backport of 2e926b041c from master
---
 docs/topics/testing/overview.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 58694a6e3f..ea475e0299 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -362,7 +362,8 @@ Some of the things you can do with the test client are:
   everything from low-level HTTP (result headers and status codes) to
   page content.
 
-* Test that the correct view is executed for a given URL.
+* See the chain of redirects (if any) and check the URL and status code at
+  each step.
 
 * Test that a given request is rendered by a given Django template, with
   a template context that contains certain values.
@@ -371,8 +372,8 @@ Note that the test client is not intended to be a replacement for Selenium_ 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
-  called and that the view is collecting the correct context data.
+* Use Django's test client to establish that the correct template is being
+  rendered and that the template is passed the correct context data.
 
 * Use in-browser frameworks like Selenium_ to test *rendered* HTML and the
   *behavior* of Web pages, namely JavaScript functionality. Django also