Merge branch 'master' of github.com:lifo/docrails

3 files changed, 46 insertions, 2 deletions

diff --git a/guides/source/command_line.textile b/guides/source/command_line.textile
index 463c2b172b..858ce47db1 100644
--- a/guides/source/command_line.textile
+++ b/guides/source/command_line.textile
@@ -278,6 +278,12 @@ The +console+ command lets you interact with your Rails application from the com
 
 You can also use the alias "c" to invoke the console: <tt>rails c</tt>.
 
+You can specify the environment in which the +console+ command should operate using the +-e+ switch.
+
+<shell>
+$ rails console -e staging
+</shell>
+
 If you wish to test out some code without changing any data, you can do that by invoking +rails console --sandbox+.
 
 <shell>
diff --git a/guides/source/engines.textile b/guides/source/engines.textile
index 501d48eab8..047f9afd76 100644
--- a/guides/source/engines.textile
+++ b/guides/source/engines.textile
@@ -219,7 +219,7 @@ By default, the scaffold styling is not applied to the engine as the engine's la
 <%= stylesheet_link_tag "scaffold" %>
 </erb>
 
-You can see what the engine has so far by running +rake db:migrate+ at the root of our engine to run the migration generated by the scaffold generator, and then running +rails server+. When you open +http://localhost:3000/blorgh/posts+ you will see the default scaffold that has been generated.
+You can see what the engine has so far by running +rake db:migrate+ at the root of our engine to run the migration generated by the scaffold generator, and then running +rails server+ in +test/dummy+. When you open +http://localhost:3000/blorgh/posts+ you will see the default scaffold that has been generated.
 
 !images/engines_scaffold.png(Blank engine scaffold)!
 
@@ -263,7 +263,7 @@ create      test/fixtures/blorgh/comments.yml
 
 This generator call will generate just the necessary model files it needs, namespacing the files under a +blorgh+ directory and creating a model class called +Blorgh::Comment+.
 
-To show the comments on a post, edit +app/views/posts/show.html.erb+ and add this line before the "Edit" link:
+To show the comments on a post, edit +app/views/blorgh/posts/show.html.erb+ and add this line before the "Edit" link:
 
 <erb>
 <h3>Comments</h3>
diff --git a/guides/source/testing.textile b/guides/source/testing.textile
index c367f532ae..60b0aa89b9 100644
--- a/guides/source/testing.textile
+++ b/guides/source/testing.textile
@@ -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+: