4 files changed, 26 insertions, 12 deletions
diff --git a/guides/source/contributing_to_ruby_on_rails.md b/guides/source/contributing_to_ruby_on_rails.md
index 17afd07820..ef3ebb1412 100644
--- a/guides/source/contributing_to_ruby_on_rails.md
+++ b/guides/source/contributing_to_ruby_on_rails.md
@@ -287,7 +287,12 @@ $ ruby -w -Itest test/mail_layout_test.rb -n test_explicit_class_layout
 The `-n` option allows you to run a single method instead of the whole
 file.
 
-##### Testing Active Record
+#### Testing Active Record
+
+First, create the databases you'll need. For MySQL and PostgreSQL, 
+running the SQL statements `create database activerecord_unittest` and 
+`create database activerecord_unittest2` is sufficient. This is not 
+necessary for SQLite3.
 
 This is how you run the Active Record test suite only for SQLite3:
 
diff --git a/guides/source/plugins.md b/guides/source/plugins.md
index 7b7eb80081..eca2e06092 100644
--- a/guides/source/plugins.md
+++ b/guides/source/plugins.md
@@ -433,7 +433,7 @@ Once your README is solid, go through and add rdoc comments to all of the method
 Once your comments are good to go, navigate to your plugin directory and run:
 
 ```bash
-$ bin/rake rdoc
+$ bundle exec rake rdoc
 ```
 
 ### References
diff --git a/guides/source/security.md b/guides/source/security.md
index b3869b1ba5..66c740f1e3 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -237,7 +237,7 @@ Or the attacker places the code into the onmouseover event handler of an image:
 <img src="http://www.harmless.com/img" width="400" height="400" onmouseover="..." />
 ```
 
-There are many other possibilities, like using a `<script>` tag to make a cross-site request to a URL with a JSONP or JavaScript response. The response is executable code that the attacker can find a way to run, possibly extracting sensitive data. To protect against this data leakage, we disallow cross-site `<script>` tags. Only Ajax requests may have JavaScript responses since XmlHttpRequest is subject to the browser Same-Origin policy - meaning only your site can initiate the request.
+There are many other possibilities, like using a `<script>` tag to make a cross-site request to a URL with a JSONP or JavaScript response. The response is executable code that the attacker can find a way to run, possibly extracting sensitive data. To protect against this data leakage, we disallow cross-site `<script>` tags. Only Ajax requests may have JavaScript responses since `XMLHttpRequest` is subject to the browser Same-Origin policy - meaning only your site can initiate the request.
 
 To protect against all other forged requests, we introduce a _required security token_ that our site knows but other sites don't know. We include the security token in requests and verify it on the server. This is a one-liner in your application controller, and is the default for newly created rails applications:
 
@@ -247,6 +247,13 @@ protect_from_forgery with: :exception
 
 This will automatically include a security token in all forms and Ajax requests generated by Rails. If the security token doesn't match what was expected, an exception will be thrown.
 
+NOTE: By default, Rails includes jQuery and an [unobtrusive scripting adapter for jQuery](https://github.com/rails/jquery-ujs),
+which adds a header called `X-CSRF-Token` on every non-GET Ajax call made by jQuery with the security token.
+Without this header, your non-GET requests won't be accepted by Rails. If you want to use another library
+to make Ajax calls, you will have to find how add the security token as a default header for Ajax calls in
+your library. To get the token have a look at the `<meta name='csrf-token' content='THE-TOKEN'>` tag printed
+by `<%= csrf_meta_tags %>` in your application view.
+
 It is common to use persistent cookies to store user information, with `cookies.permanent` for example. In this case, the cookies will not be cleared and the out of the box CSRF protection will not be effective. If you are using a different cookie store than the session for this information, you must handle what to do with it yourself:
 
 ```ruby
diff --git a/guides/source/testing.md b/guides/source/testing.md
index b22da70031..32140be704 100644
--- a/guides/source/testing.md
+++ b/guides/source/testing.md
@@ -175,18 +175,18 @@ A line by line examination of this file will help get you oriented to Rails test
 require 'test_helper'
 ```
 
-As you know by now, `test_helper.rb` specifies the default configuration to run our tests. This is included with all the tests, so any methods added to this file are available to all your tests.
+By requiring this file, `test_helper.rb` the default configuration to run our tests is loaded. We will include this with all the tests we write, so any methods added to this file are available to all your tests.
 
 ```ruby
 class ArticleTest < ActiveSupport::TestCase
 ```
 
-The `ArticleTest` class defines a _test case_ because it inherits from `ActiveSupport::TestCase`. `ArticleTest` thus has all the methods available from `ActiveSupport::TestCase`. You'll see those methods a little later in this guide.
+The `ArticleTest` class defines a _test case_ because it inherits from `ActiveSupport::TestCase`. `ArticleTest` thus has all the methods available from `ActiveSupport::TestCase`. Later in this guide, you'll see some of the methods it gives you.
 
 Any method defined within a class inherited from `Minitest::Test`
-(which is the superclass of `ActiveSupport::TestCase`) that begins with `test_` (case sensitive) is simply called a test. So, `test_password` and `test_valid_password` are legal test names and are run automatically when the test case is run.
+(which is the superclass of `ActiveSupport::TestCase`) that begins with `test_` (case sensitive) is simply called a test. So, methods defined as `test_password` and `test_valid_password` are legal test names and are run automatically when the test case is run.
 
-Rails adds a `test` method that takes a test name and a block. It generates a normal `Minitest::Unit` test with method names prefixed with `test_`. So,
+Rails also adds a `test` method that takes a test name and a block. It generates a normal `Minitest::Unit` test with method names prefixed with `test_`. So you don't have to worry about naming the methods, and you can write something like:
 
 ```ruby
 test "the truth" do
@@ -194,7 +194,7 @@ test "the truth" do
 end
 ```
 
-acts as if you had written
+Which is approximately the same as writing this:
 
 ```ruby
 def test_the_truth
@@ -202,22 +202,24 @@ def test_the_truth
 end
 ```
 
-only the `test` macro allows a more readable test name. You can still use regular method definitions though.
+However only the `test` macro allows a more readable test name. You can still use regular method definitions though.
 
-NOTE: The method name is generated by replacing spaces with underscores. The result does not need to be a valid Ruby identifier though, the name may contain punctuation characters etc. That's because in Ruby technically any string may be a method name. Odd ones need `define_method` and `send` calls, but formally there's no restriction.
+NOTE: The method name is generated by replacing spaces with underscores. The result does not need to be a valid Ruby identifier though, the name may contain punctuation characters etc. That's because in Ruby technically any string may be a method name. This may require use of `define_method` and `send` calls to function properly, but formally there's little restriction on the name.
+
+Next, let's look at our first assertion:
 
 ```ruby
 assert true
 ```
 
-This line of code is called an _assertion_. An assertion is a line of code that evaluates an object (or expression) for expected results. For example, an assertion can check:
+An assertion is a line of code that evaluates an object (or expression) for expected results. For example, an assertion can check:
 
 * does this value = that value?
 * is this object nil?
 * does this line of code throw an exception?
 * is the user's password greater than 5 characters?
 
-Every test contains one or more assertions. Only when all the assertions are successful will the test pass.
+Every test must contain at least one assertion, with no restriction as to how many assertions are allowed. Only when all the assertions are successful will the test pass.
 
 ### Maintaining the test database schema