Document more simple testing setup.

Author: metaskills

RUNNING_UNIT_TESTS

@@ -1,4 +1,13 @@
 
+= TL;DR
+
+  * Setup two databases in SQL Server, [activerecord_unittest] and [activerecord_unittest2]
+  * Create a [rails] user with an empty password and give it admin perms to both DBs.
+  * $ git clone git://github.com/rails-sqlserver/activerecord-sqlserver-adapter.git
+  * $ bundle install
+  * $ bundle exec rake test
+
+  
 = Creating the test databases
 
 The default names for the test databases are "activerecord_unittest" and 
@@ -21,36 +30,44 @@ Clone adapter git://github.com/rails-sqlserver/activerecord-sqlserver-adapter.gi
 The master branch is the one under development for rails 3, track the repos 2-3-stable 
 branch for 2.x development.
 
-The tests of this adapter depend on the existence of the rails which can be cloned at 
-git://github.com/rails/rails.git
+The tests of this adapter depend on the existence of the rails which under the 3.1 
+version and above is automatically cloned for you with bundler. However you can clone
+rails from git://github.com/rails/rails.git and set the RAILS_SOURCE environment 
+variable so bundler will use another local path instead.
 
-Once you have cloned these repos set the RAILS_SOURCE environment variable to its 
-full path. For instance:
+  $ git clone git://github.com/rails-sqlserver/activerecord-sqlserver-adapter.git
 
-  ∴ echo $RAILS_SOURCE
-  /Users/kencollins/Repositories/rails
-  
-Do not forget to checkout the version tags of each repo that match either our gemspec 
-or what version your tests target. For instance, v3.0.3 tag for Rails/ActiveRecord.
+
+= Bundling
+
+Now with that out of the way you can run "bundle install" to hook everything up. 
+Our tests use bundler to setup the load paths correctly. The default mode is DBLIB
+using TinyTDS. It is important to use bundle exec so we can wire up the ActiveRecord
+test libs correctly.
+
+  $ bundle exec rake test
 
 
-= Setup Connection Mode
+= Testing Options
 
 The Gemfile contains groups for :tinytds and :odbc. By default it will install both gems 
 which allows you to run the full test suite in either connection mode. If for some reason 
-any one of these is problematic or of no concern, you could always for go the bundling 
-of those gems with something like this.
+any one of these is problematic or of no concern, you could always opt out of bundling 
+either gem with something like this.
 
-  ∴ bundle install --without odbc
+  $ bundle install --without odbc
 
+You can run different connection modes using the following rake commands. Again, the 
+DBLIB connection mode using TinyTDS is the default test task.
 
-= Finally
+  $ bundle exec rake test:dblib
+  $ bundle exec rake test:odbc
 
-Now with all that out of the way you can run "bundle install" to hook everything up. 
-Our tests use bundler to setup the load paths correctly. If all goes well, you should 
-be able to run "rake test:dblib" which will load all the adapter tests followed by the 
-core ActiveRecord tests. Lastly, it is typically good practice to do your work 
-on a local branch of our remote tracking branch.
+By default, Bundler will download the rails git repo and use the git tag that matches 
+the dependency version in our gemspec. If you want to test another version of rails, 
+you can either temporarily change the :tag for rails in the Gemfile. Likewise, you can
+clone the rails repo your self to another directory and use the RAILS_SOURCE environment 
+variable.
 
 
 = Current Expected Failures