sauron 0.1.22 → 0.1.23

data/README.rdoc

@@ -1,22 +1,34 @@
 = Sauron
 
-The all-seeing testing toolkit with many workers. Think multi-threaded, multi-database autotest. It continually watches your application for code changes like autotest, then runs them multi-threaded, each thread having its own database, to take maximum advantage of your computer's multiple cores/processors. Fast!
+The all-seeing testing toolkit with many workers. Think multi-threaded, multi-database autotest. 
+It continually watches your application for code changes like autotest, then runs them 
+multi-threaded, each thread having its own database, to take maximum advantage of your computer's 
+multiple cores/processors. Fast!
 
 == Why a new testing toolkit?
 
-For a long time, my holy grail of testing has been multi-threaded autotest.  Autotest is awesome, watching my application in real time and only running tests for code that has changed. But it doesn't take advantage of the growing number of cores and processors that computers have today.
+For a long time, my holy grail of testing has been multi-threaded autotest.  Autotest is awesome, 
+watching my application in real time and only running tests for code that has changed. But it 
+doesn't take advantage of the growing number of cores and processors that computers have today.
 
-Parallel_specs solves the multi-threaded, multi-database problem, but it has to be run manually, and runs all your tests at once. It also doesn't split up the test suite very efficiently, resulting in one thread finishing significantly sooner than the other. 
+Parallel_specs solves the multi-threaded, multi-database problem, but it has to be run manually, 
+and runs all your tests at once. It also doesn't split up the test suite very efficiently, 
+resulting in one thread finishing significantly sooner than the other. 
 
 == How does it work?
 
-Sauron uses the watchr gem to watch your rails files for changes, and runs only the tests related to those changes. Sauron comes with a basic, but user-changeable, watchr script. This part is much like autotest.
+Sauron uses the watchr gem to watch your rails files for changes, and runs only the tests related 
+to those changes. Sauron comes with a basic, but user-changeable, watchr script. This part is much 
+like autotest.
 
-When Sauron detects that tests need to be run, it runs single tests with a direct ruby command. If there are multiple files, however, it kicks off a customized version of the hydra gem, creating multiple workers to run pieces of the test suite efficiently.
+When Sauron detects that tests need to be run, it runs single tests with a direct ruby command. If 
+there are multiple files, however, it kicks off a customized version of the hydra gem, creating 
+multiple workers to run pieces of the test suite efficiently.
 
 == How do I use it?
 
-WARNING: This is still a *very* new gem (only in existence since July 17th, 2010).  Use very carefully.
+WARNING: This is still a *very* new gem (only in existence since July 17th, 2010).  Use very
+carefully.
 
 === Include the gems
 
@@ -24,13 +36,15 @@ The first step is to include the necessary gems in your config/environments/test
 
   config.gem 'sauron'
 
-The is the Sauron gem, which will also include the Watchr gem and a fork of the Hydra gem that I modified to support multiple databases. To get them on your system, run:
+The is the Sauron gem, which will also include the Watchr gem and a fork of the Hydra gem that I 
+modified to support multiple databases. To get them on your system, run:
 
   rake gems:install RAILS_ENV=test 
 
 === Edit your database configuration
 
-Edit your config/database.yml so that your test database name includes the worker number environment variable.  Here's an example:
+Edit your config/database.yml so that your test database name includes the worker number 
+environment variable.  Here's an example:
 
   test:
     adapter: mysql
@@ -42,11 +56,15 @@ Or for sqlite3:
     adapter: sqlite3
     database: app_test<%= ENV['HYDRA_WORKER_ID'] %>.sqlite3
 
+Aside from sqlite, you might have an extra step depending on your database permissions. See
+"Caveats" below.
+
 === Run the Sauron generator
 
   ruby script/generate sauron
 
-By default, it will create a setup with 4 workers (threads/databases used during tests) and assume you are using testunit. You can change both of these with commandline arguments:
+By default, it will create a setup with 4 workers (threads/databases used during tests) and assume 
+you are using testunit. You can change both of these with commandline arguments:
 
   ruby script/generate sauron --workers=10 --rspec
 
@@ -58,23 +76,61 @@ While developing your rails app, run:
 
   ruby script/sauron
 
-which will launch Sauron and watch your app. Use Ctrl-\ to refresh your testing suite after adding files. Ta-da! Multi-threaded, multi-database, automatic testing goodness!
+which will launch Sauron and watch your app. Use Ctrl-\ to refresh your testing suite after adding 
+files. Ta-da! Multi-threaded, multi-database, automatic testing goodness!
 
 == For advanced users
 
-The generator creates a watchr script called sauron_watchr.rb in the root directory of your app. I think it has a good basic setup, but customize it all  you want.
+The generator creates a watchr script called sauron_watchr.rb in the root directory of your app. I 
+think it has a good basic setup, but customize it all  you want.
 
 == For really advanced users
 
-Help me make this tool better. Fork it, fix it, send a pull request. My low public profile and crippling need for acceptance ensure you'll get a prompt, friendly response.
+Help me make this tool better. Fork it, fix it, send a pull request. My low public profile and 
+crippling need for acceptance ensure you'll get a prompt, friendly response.
 
 == Caveats
 
-This is very new. I can't see how it would damage anything, but I guess that's what everyone says before they damage something. Also, I've traditionally used shoulda over rspec, so there may be glitches in what files Sauron watches/runs in rspec mode.  If you see something wrong, let me know.
+==== MySQL, PostgreSQL, and other big kids
+
+Sqlite is fun, but with real databases come issues like permissions.  If you have liberal local
+permissions on your database, like root with no password from localhost, you shouldn't have to do
+anything extra to prepare your db's.
+
+If you're more paranoid like me, and assign a unique user/pass for each app on your local system,
+you'll need to create the extra databases and grant privileges in advance.  It's easy, just create
+more test databases with numbers appended in this fashion:
+
+* app_test
+* app_test1
+* app_test2
+* app_test3
+
+And so forth, as many databases as you'll have workers.  These three lines work nicely in MySQL:
+
+  create database app_test1;
+  grant all on app_test1.* to turtle@localhost identified by 'secretpassword';
+  flush privileges;
+
+Substitute your chosen username and password above, instead of 'turtle' and 'secretpassword', 
+respectively. Do this to create each new database.
+
+==== Full Hydra support?  No!
+
+While the Hydra gem supports multiple computers over a network, Sauron doesn't at this time. That 
+might become a priority if people ask. It will definitely become a priority if somebody buys me a 
+multi-core system I can add to my testing arsenal :)
+
+==== Newness/shoddiness
 
-While the Hydra gem supports multiple computers over a network, Sauron doesn't at this time. That might become a priority if people ask. It will definitely become a priority if somebody buys me a multi-core system I can add to my testing arsenal :)
+This is very new. I can't see how it would damage anything, but I guess that's what everyone says 
+before they damage something. Also, I've traditionally used shoulda over rspec, so there may be 
+glitches in what files Sauron watches/runs in rspec mode.  If you see something wrong, let me know.
 
-This was put together quickly. If you don't feel like the underlying code is beautiful, this was largely hacked together during Ruby Midwest weekend, during hours that should have been used for sleeping.
+Also, this was put together quickly. If you don't feel like the underlying code is beautiful, this 
+was largely hacked together during Ruby Midwest weekend, during hours that should have been used 
+for sleeping. If you *still* feel slighted, I will offer you a full refund of what you paid for 
+this gem. No questions asked!
 
 
 Copyright (c) 2010 Jaime Bellmyer, released under the MIT license

data/VERSION

@@ -1 +1 @@
-0.1.22
+0.1.23

data/lib/sauron/sauron_template.rb

@@ -135,8 +135,10 @@ class SauronTemplate
       print '.'
       STDOUT.flush
 
-      i = '' if i == 0
-      `rake db:reset RAILS_ENV=test HYDRA_WORKER_ID=#{i}`
+      hydra_worker_id = (i == 0 ? '' : i)
+      test_env_number = (i == 0 ? '' : i + 1)
+      
+      `rake db:reset RAILS_ENV=test HYDRA_WORKER_ID=#{hydra_worker_id} TEST_ENV_NUMBER=#{test_env_number}`
     end
   end
 

data/sauron.gemspec

@@ -5,11 +5,11 @@
 
 Gem::Specification.new do |s|
   s.name = %q{sauron}
-  s.version = "0.1.22"
+  s.version = "0.1.23"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.authors = ["Jaime Bellmyer"]
-  s.date = %q{2010-07-19}
+  s.date = %q{2010-07-20}
   s.description = %q{Speed up your automated tests with multiple databases and workers.}
   s.email = %q{jaime@kconrails.com}
   s.extra_rdoc_files = [

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: sauron
 version: !ruby/object:Gem::Version 
-  hash: 55
+  hash: 53
   prerelease: false
   segments: 
   - 0
   - 1
-  - 22
-  version: 0.1.22
+  - 23
+  version: 0.1.23
 platform: ruby
 authors: 
 - Jaime Bellmyer
@@ -15,7 +15,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2010-07-19 00:00:00 -05:00
+date: 2010-07-20 00:00:00 -05:00
 default_executable: 
 dependencies: 
 - !ruby/object:Gem::Dependency