1 files changed, 39 insertions, 1 deletions

diff --git a/guides/source/testing.textile b/guides/source/testing.textile
index c367f532ae..d35be6a70e 100644
--- a/guides/source/testing.textile
+++ b/guides/source/testing.textile
@@ -412,7 +412,7 @@ NOTE: +assert_valid(record)+ has been deprecated. Please use +assert(record.vali
 |+assert_no_difference(expressions, message = nil, &block)+                     |Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.|
 |+assert_recognizes(expected_options, path, extras={}, message=nil)+                |Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.|
 |+assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)+  |Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.|
-|+assert_response(type, message = nil)+                                             |Asserts that the response comes with a specific status code. You can specify +:success+ to indicate 200,  +:redirect+ to indicate 300-399, +:missing+ to indicate 404, or +:error+ to match the 500-599 range|
+|+assert_response(type, message = nil)+                                             |Asserts that the response comes with a specific status code. You can specify +:success+ to indicate 200-299,  +:redirect+ to indicate 300-399, +:missing+ to indicate 404, or +:error+ to match the 500-599 range|
 |+assert_redirected_to(options = {}, message=nil)+                                  |Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such that +assert_redirected_to(:controller => "weblog")+ will also match the redirection of +redirect_to(:controller => "weblog", :action => "show")+ and so on.|
 |+assert_template(expected = nil, message=nil)+                                     |Asserts that the request was rendered with the appropriate template file.|
 
@@ -524,6 +524,44 @@ You also have access to three instance variables in your functional tests:
 * +@request+ - The request
 * +@response+ - The response
 
+h4. Testing Templates and Layouts
+
+If you want to make sure that the response rendered the correct template and layout, you can use the +assert_template+ 
+method:
+
+<ruby>
+test "index should render correct template and layout" do
+  get :index
+  assert_template :index
+  assert_template :layout => "layouts/application"
+end
+</ruby>
+
+Note that you cannot test for template and layout at the same time, with one call to +assert_template+ method.
+Also, for the +layout+ test, you can give a regular expression instead of a string, but using the string, makes
+things clearer. On the other hand, you have to include the "layouts" directory name even if you save your layout
+file in this standard layout directory. Hence,
+
+<ruby>
+assert_template :layout => "application"
+</ruby>
+
+will not work.
+
+If your view renders any partial, when asserting for the layout, you have to assert for the partial at the same time.
+Otherwise, assertion will fail.
+
+Hence:
+
+<ruby>
+test "new should render correct layout" do
+  get :new
+  assert_template :layout => "layouts/application", :partial => "_form"
+end
+</ruby>
+
+is the correct way to assert for the layout when the view renders a partial with name +_form+. Omitting the +:partial+ key in your +assert_template+ call will complain.
+
 h4. A Fuller Functional Test Example
 
 Here's another example that uses +flash+, +assert_redirected_to+, and +assert_difference+: