6 files changed, 23 insertions, 64 deletions
diff --git a/guides/source/3_1_release_notes.md b/guides/source/3_1_release_notes.md
index 537aa5a371..d753346fa3 100644
--- a/guides/source/3_1_release_notes.md
+++ b/guides/source/3_1_release_notes.md
@@ -199,7 +199,7 @@ Railties
 
 * jQuery is the new default JavaScript library.
 
-* jQuery and Prototype are no longer vendored and is provided from now on by the jquery-rails and prototype-rails gems.
+* jQuery and Prototype are no longer vendored and is provided from now on by the `jquery-rails` and `prototype-rails` gems.
 
 * The application generator accepts an option `-j` which can be an arbitrary string. If passed "foo", the gem "foo-rails" is added to the `Gemfile`, and the application JavaScript manifest requires "foo" and "foo_ujs". Currently only "prototype-rails" and "jquery-rails" exist and provide those files via the asset pipeline.
 
diff --git a/guides/source/association_basics.md b/guides/source/association_basics.md
index 1fe111f2a0..b9c9995a79 100644
--- a/guides/source/association_basics.md
+++ b/guides/source/association_basics.md
@@ -435,7 +435,7 @@ end
 
 The simplest rule of thumb is that you should set up a `has_many :through` relationship if you need to work with the relationship model as an independent entity. If you don't need to do anything with the relationship model, it may be simpler to set up a `has_and_belongs_to_many` relationship (though you'll need to remember to create the joining table in the database).
 
-You should use `has_many :through` if you need validations, callbacks, or extra attributes on the join model.
+You should use `has_many :through` if you need validations, callbacks or extra attributes on the join model.
 
 ### Polymorphic Associations
 
diff --git a/guides/source/debugging_rails_applications.md b/guides/source/debugging_rails_applications.md
index 96bf532868..dc1df8f229 100644
--- a/guides/source/debugging_rails_applications.md
+++ b/guides/source/debugging_rails_applications.md
@@ -531,8 +531,11 @@ command later in this guide).
 And then ask again for the instance_variables:
 
 ```
-(byebug) instance_variables.include? "@articles"
-true
+(byebug) instance_variables
+[:@_action_has_layout, :@_routes, :@_headers, :@_status, :@_request,
+ :@_response, :@_env, :@_prefixes, :@_lookup_context, :@_action_name,
+ :@_response_body, :@marked_for_same_origin_verification, :@_config,
+ :@articles]
 ```
 
 Now `@articles` is included in the instance variables, because the line defining it
diff --git a/guides/source/kindle/welcome.html.erb b/guides/source/kindle/welcome.html.erb
index 610a71570f..ef3397f58f 100644
--- a/guides/source/kindle/welcome.html.erb
+++ b/guides/source/kindle/welcome.html.erb
@@ -2,4 +2,6 @@
 
 <h3>Kindle Edition</h3>
 
-The Kindle Edition of the Rails Guides should be considered a work in progress. Feedback is really welcome. Please see the "Feedback" section at the end of each guide for instructions.
+<div>
+  The Kindle Edition of the Rails Guides should be considered a work in progress. Feedback is really welcome. Please see the "Feedback" section at the end of each guide for instructions.
+</div>
diff --git a/guides/source/rails_application_templates.md b/guides/source/rails_application_templates.md
index b3e1874048..b7364536c3 100644
--- a/guides/source/rails_application_templates.md
+++ b/guides/source/rails_application_templates.md
@@ -215,7 +215,7 @@ CODE
 
 ### yes?(question) or no?(question)
 
-These methods let you ask questions from templates and decide the flow based on the user's answer. Let's say you want to freeze rails only if the user wants to:
+These methods let you ask questions from templates and decide the flow based on the user's answer. Let's say you want to Freeze Rails only if the user wants to:
 
 ```ruby
 rake("rails:freeze:gems") if yes?("Freeze rails gems?")
diff --git a/guides/source/testing.md b/guides/source/testing.md
index 2067fdb383..230e8162f3 100644
--- a/guides/source/testing.md
+++ b/guides/source/testing.md
@@ -467,7 +467,6 @@ Rails adds some custom assertions of its own to the `minitest` framework:
 | `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-299, `:redirect` to indicate 300-399, `:missing` to indicate 404, or `:error` to match the 500-599 range. You can also pass an explicit status number or its symbolic equivalent. For more information, see [full list of status codes](http://rubydoc.info/github/rack/rack/master/Rack/Utils#HTTP_STATUS_CODES-constant) and how their [mapping](http://rubydoc.info/github/rack/rack/master/Rack/Utils#SYMBOL_TO_STATUS_CODE-constant) works.|
 | `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. You can also pass named routes such as `assert_redirected_to root_path` and Active Record objects such as `assert_redirected_to @article`.|
-| `assert_template(expected = nil, message=nil)`                                    | Asserts that the request was rendered with the appropriate template file.|
 
 You'll see the usage of some of these assertions in the next chapter.
 
@@ -506,16 +505,18 @@ Now that we have used Rails scaffold generator for our `Article` resource, it ha
 Let me take you through one such test, `test_should_get_index` from the file `articles_controller_test.rb`.
 
 ```ruby
+# articles_controller_test.rb
 class ArticlesControllerTest < ActionController::TestCase
   test "should get index" do
     get :index
     assert_response :success
-    assert_not_nil assigns(:articles)
+    assert_includes @response.body, 'Articles'
   end
 end
 ```
 
-In the `test_should_get_index` test, Rails simulates a request on the action called `index`, making sure the request was successful and also ensuring that it assigns a valid `articles` instance variable.
+In the `test_should_get_index` test, Rails simulates a request on the action called `index`, making sure the request was successful
+and also ensuring that the right response body has been generated.
 
 The `get` method kicks off the web request and populates the results into the response. It accepts 4 arguments:
 
@@ -553,7 +554,7 @@ test "should create article" do
     post :create, params: { article: { title: 'Some title' } }
   end
 
-  assert_redirected_to article_path(assigns(:article))
+  assert_redirected_to article_path(Article.last)
 end
 ```
 
@@ -580,11 +581,11 @@ To test AJAX requests, you can specify the `xhr: true` option to `get`, `post`,
 `patch`, `put`, and `delete` methods:
 
 ```ruby
-test "ajax request responds with no layout" do
+test "ajax request" do
   get :show, params: { id: articles(:first).id }, xhr: true
 
-  assert_template :index
-  assert_template layout: nil
+  assert_equal 'hello world', @response.body
+  assert_equal "text/javascript", @response.content_type
 end
 ```
 
@@ -592,20 +593,16 @@ end
 
 After a request has been made and processed, you will have 4 Hash objects ready for use:
 
-* `assigns` - Any objects that are stored as instance variables in actions for use in views.
 * `cookies` - Any cookies that are set.
 * `flash` - Any objects living in the flash.
 * `session` - Any object living in session variables.
 
-As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for `assigns`. For example:
+As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name. For example:
 
 ```ruby
 flash["gordon"]               flash[:gordon]
 session["shmession"]          session[:shmession]
 cookies["are_good_for_u"]     cookies[:are_good_for_u]
-
-# Because you can't use assigns[:something] for historical reasons:
-assigns["something"]          assigns(:something)
 ```
 
 ### Instance Variables Available
@@ -633,46 +630,6 @@ get :index # simulate the request with custom header
 post :create # simulate the request with custom env variable
 ```
 
-### Testing Templates and Layouts
-
-Eventually, you may want to test whether a specific layout is rendered in the view of a response.
-
-#### Asserting Templates
-
-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"
-
-  # You can also pass a regular expression.
-  assert_template layout: /layouts\/application/
-end
-```
-
-NOTE: You cannot test for template and layout at the same time, with a single call to `assert_template`.
-
-WARNING: You must include the "layouts" directory name even if you save your layout file in this standard layout directory. Hence, `assert_template layout: "application"` will not work.
-
-#### Asserting Partials
-
-If your view renders any partial, when asserting for the layout, you can to assert for the partial at the same time.
-Otherwise, assertion will fail.
-
-Remember, we added the "_form" partial to our new Article view? Let's write an assertion for that in the `:new` action now:
-
-```ruby
-test "new should render correct layout" do
-  get :new
-  assert_template layout: "layouts/application", partial: "_form"
-end
-```
-
-This is the correct way to assert for when the view renders a partial with a given name. As identified by the `:partial` key passed to the `assert_template` call.
-
 ### Testing `flash` notices
 
 If you remember from earlier one of the Four Hashes of the Apocalypse was `flash`.
@@ -688,7 +645,7 @@ test "should create article" do
     post :create, params: { article: { title: 'Some title' } }
   end
 
-  assert_redirected_to article_path(assigns(:article))
+  assert_redirected_to article_path(Article.last)
   assert_equal 'Article was successfully created.', flash[:notice]
 end
 ```
@@ -781,7 +738,7 @@ We can also add a test for updating an existing Article.
 test "should update article" do
   article = articles(:one)
   patch :update, params: { id: article.id, article: { title: "updated" } }
-  assert_redirected_to article_path(assigns(:article))
+  assert_redirected_to article_path(article)
 end
 ```
 
@@ -820,7 +777,7 @@ class ArticlesControllerTest < ActionController::TestCase
 
   test "should update article" do
     patch :update, params: { id: @article.id, article: { title: "updated" } }
-    assert_redirected_to article_path(assigns(:article))
+    assert_redirected_to article_path(@article)
   end
 end
 ```
@@ -857,7 +814,6 @@ class ProfileControllerTest < ActionController::TestCase
 
     get :show
     assert_response :success
-    assert_equal users(:david), assigns(:user)
   end
 end
 ```
@@ -1071,14 +1027,12 @@ How about testing our ability to create a new article in our blog and see the re
 test "can create an article" do
   get "/articles/new"
   assert_response :success
-  assert_template "articles/new", partial: "articles/_form"
 
   post "/articles",
     params: { article: { title: "can create", body: "article successfully." } }
   assert_response :redirect
   follow_redirect!
   assert_response :success
-  assert_template "articles/show"
   assert_select "p", "Title:\n  can create"
 end
 ```