First off you’re going to have to create the actual configuration object. There are a few good ways to do this. One is to use a config module, another is to create a configuration object that is accessible via a singleton method.

I’m going to go with the second one, a configuration object.

Toss this one in lib/configuration.rb (A simplification of Code | RDoc)

module Plugin

  # Configures Plugin.
  def self.configure(configuration = Plugin::Configuration.new)
    yield configuration if block_given?
    @@configuration = configuration
  end

  def self.configuration # :nodoc:
    @@configuration ||= Plugin::Configuration.new
  end

  # Plugin can be configured using the Plugin.configure method. For example:
  #
  #   Plugin.configure do |config|
  #     config.show_whiny_errors = false
  #   end
  class Configuration

    # Should whiny error messages be shown?
    attr_writer :show_whiny_errors

    def initialize # :nodoc:
      # set your defaults in here
      self.show_whiny_errors = true
      # put as much as you want in here
    end

    # some syntactic sugar for you, the coder
    def show_whiny_errors? #:nodoc:
      @show_whiny_erorrs ? true : false
    end

  end

end

Okay, now we need to test the config object itself. This is why it’s nice to make an object just to house the config, it’s easy to test. What do we test? Well defaults and accessors for two!

(The following lifted from Code) (sorry this is in rspec, it’s not hard to do in test::unit)

require File.expand_path(File.dirname(__FILE__) + '/../../spec_helper')

describe Plugin::Configuration do
  # define matchers for testing
  predicate_matchers[:show_whiny_errors] = :show_whiny_errors?

  it 'should show whiny errors by default' do
    config = Plugin::Configuration.new
    config.should show_whiny_errors?
  end

  it 'should be configurable with a block' do
    Plugin.configure do |config|
      config.show_whiny_errors = false
    end

    config = Plugin.configuration
    config.should_not show_whiny_errors?
  end

end

Now we need to do some stuff to make it nicer for our other users to test. Put the following in your test_helper or spec helper. It will allow you to clear your config after each test. Nice to have to to avoid messy test issues.

(The following lifted from Code)

module Plugin
  @@previous_config = nil

  def self.cache_config_for_test
    @@previous_config = Plugin.configuration.clone
  end

  def self.reset_for_test
    @@configuration = @@previous_config if @@previous_config
  end
end

# configure your test runner / spec runner to always clear the config
Spec::Runner.configure do |config|

  config.before :each do
    Plugin.cache_config_for_test
  end

  config.after :each do
    Plugin.reset_for_test
  end
end

This last bit is somewhat hard to do in test::unit as it is harder to hook into the setup (you only get one in the call chain). I’m willing to take some help on cleaning this one up for test::unit. Currently I have just been putting it in the setup / teardown for each test file.

Finally you need to make use of this in tests, fortunately that is quite easy. Just:

describe SomeObject do
    it 'it shouldn't do it when whiny nils are off' do
      Plugin.configure do |config|
        config.show_whiny_errors = false
      end
      object.should_not_receive(:log)

      object.do_somthing_that_usually_complains
    end
end

Finally, anywhere in your plugin that you think somthing is whiny, just check the config before using it like this:

log("you should really fix this") if Plugin.configuration.show_whiny_errors?

• Library: Generates a non active record ruby object and a test class.
  • lib/library_name.rb
  • test/unit/library_name_test.rb
• Module: Generates a basic module under lib and its tests.
  • lib/module_name.rb
  • test/unit/module_name_test.rb, with a mock class that mixes in the library
• Base Generator: Generates a generator (mmm meta) with a template, usage and manifest.
  • lib/generators/generator_name/generator_name_generator.rb
  • lib/generators/generator_name/USAGE
  • lib/generators/generator_name/templates

The plugin is at: http://github.com/gaffo/generator_missing / git://github.com/gaffo/generator_missing.git
Lighthouse at http://gaffo.lighthouseapp.com/projects/21321-generator_missing/overview.

I am currently taking both suggestions and pull requests for generators that should be added.

Currently there is a delay for as I am manually vetting and configuring the libraries. Unfortunately not everyone is creating the .documentation file or using the same rake task (rdoc, doc, docs) or doc directory (rdoc, doc, docs) so I have to give it a quick once over.

Please let check it out and let me know what you think.

Say we have a named scope in our member object which looks like this:

class Member < ActiveRecord::Base
  named_scope :active, {:conditions => {:status => Member::STATUS_ACTIVE}}
end

There are 2 things we need to do to test them.

First would be to make sure that the conditions are the same as we think they are. This one is open for debate a bit as it is somewhat tying the implementation directly to the test.

Second, we actually have to USE the scope. Just calling Member.active does not actually use the scope. This is because named scopes can be cascaded. If I had recent scope on a member that only showed me those that signed up recently, I could actually do Member.active.recent, and it would not execute against database, it would just nest the conditions.

So how do I use the scope? Use any collection method on them. I like size, but I’m completely open to suggestions. So below is how I am testing named scopes.

class MemberTest < ActiveRecord::TestCase
  context 'named scope active' do
    setup do
      @scoped_find = Member.active
    end

    should "have condition active" do
      expected_conditions  = {:conditions => ["member.status == #{Member::STATUS_ACTIVE}"]}
      assert_equal expected_conditions, @scoped_find.proxy_options
    end

    should "have results" do
      assert_not_nil(scoped.active.size)
    end
  end
end

The first test does part 1, the 2nd, part 2.

Object:

class User
  validates_presence_of :first_name, :last_name, :company_id
  belongs_to :company
  def full_name
    "#{last_name}, #{first_name}"
  end
  def company_name
    company.name
  end
end

Test:

class UserTest < Test::Unit
  def test_full_name
    assert_equal("Gaffney, Mike", User.new(:first_name => "Mike", :last_name => "Gaffney"))
  end
  def test_company_name
    company = Company.new(:name => "CompanyName")
    user = User.new(:company => company)
    assert_equal("CompanyName", user.company_name)
  end
end

This may seem like overkill but when many people are looking at the code it greatly helps communicate intention to others.

Testing:

I also found several methods to test protected and private methods in ruby, so I will cover the pluses and minuses the ones I know of.

Lets say we have a User class and an unassociated comments class. Comments are only attributed to a poster’s full name. There is no direct ID link between comments and users.

class User
  validates_presence_of :first_name, :last_name
  def find_comments
    Comments.find(:all, :conditions => {:poster => full_name})
  end
  protected
  def full_name
    "#{last_name}, #{first_name}"
  end
end

Here are the approaches I’m going to use to test this:

• Using a Mock to open access restrictions
• Make single (protected/private) methods public on the tested class.
• Make all (protected/private) methods public on the tested class.
• Hybrid Mock Approach
• Using instance_eval and send
• send

Using Mocks:
Mocks should be pretty familiar to most developers. Basically you create a class or subclass that the test will use. In our case we are simply opening the access restrictions with a subclass. Our test class looks like this:

class MockUser < User
  def full_name
    super
  end
end
class UserTest < Test::Unit
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

Plusses:

• Simple and familiar to most developers from many languages

Minuses:

• Can’t test private methods (subclass doesn’t have access).
• With complicated classes you end up with quite a few mocks for all of the different cases. Managing the mocks becomes tedious.

Make single methods public:
Next we will make use of the runtime nature of ruby to change a function from protected to public. This also works for private methods:

class UserTest < Test::Unit
  def test_full_name
    User.send(:public, :first_name)
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

or

class User
    public :first_name
end
class UserTest < Test::Unit
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

Plusses:

• Lets us directly access the private or protected function.

Minuses:

• This pollutes the default namespace for all of the other tests. Remember that tests can (and should be able to) run in random order. Take for example:
  1. Full Name is a public function that some other objects use.
  2. We make this function into a protected one and use this method to make it public for testing.
  3. If this new test runs before the tests for the objects using the old public full_name, full_name will still be public even though it is actually protected.
  4. The other tests do not fail but the code will fail during runtime.

Make all methods public:
To save us some time on a big class, we can make all private and protected methods public:

class User
  public *protected_methods.collect(&:to_sym)
  public *private_methods.collect(&:to_sym)
end
class UserTest
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

or

class UserTest < Test::Unit
  def test_full_name
    User.send(:public, *MyClass.protected_instance_methods)
    User.send(:public, *MyClass.private_instance_methods)
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

This has the same issues as above but can be done one to make large classes easy to test, especially using the first method.

Hybrid Approach:
This works like the mock example and the previous example combined:

class AllAccessUser
  public *protected_methods.collect(&amp:to_sym)
end
class UserTest < Test::Unit
  def test_full_name
    user = AllAccessUser.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

This is easy like the previous but does not pollute the namespace. However it cannot be used for private methods.

Using send
Now we will use the built in reflection method to call the protected/private method on the class. This makes use of the fact that protected and private in ruby aren’t really like protected and private in other languages.

class UserTest < Test::Unit
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.send(:full_name))
  end
end

Plusses:

• Doesn’t pollute the namespace.
• All code is right in the test.
• Works for protected and private.

Minuses:

• Some people don’t like using send

Summary:
Testing protected and private methods should be done, and ruby makes it much easier than some other languages. My preferred technique is the final one of using send. It is slightly less readable but keeps everything contained in one location.

task  verwrite_database_yml_file do
  run "[ -f /var/rails/#{application}/database.yml ] && cp -f /var/rails/#{application}/database.yml #{latest_release}/config/ || echo 'database.yml was not overwritten'"
end
after "deploy:update_code",  verwrite_database_yml_file

And place a database.yml file containing only your production connection information in the same directory as current and shared (eg the deploy_to directory). In fact I typically take the production information out of the config/database.yml entirely.

When deploy runs, if it finds a database.yml file in the deploy_to directory, it will copy it into config before migrating or starting the application. You can use this task to copy other configuration files that you want to keep out of source control as well, but I think its a good idea to only have the database connect info and host names change between deployments.

User.new(:name => “tony”){|u| u.save}

which is great for active record tests.

Or in a bigger example:

@trip = Trip.new{|t| t.save!}
@invite1 = Invitation.new(:user => users(:aaron),
                                   :status => Invitation::STATUS_MAYBE){|i| i.save}
@invite1 = Invitation.new(:user => users(:aaron),
                                   :status => Invitation::STATUS_MAYBE){|i| i.save}

Add the following to the Rakefile in the root of your rails app:

require 'rcov/rcovtask'

namespace :test do
namespace :coverage do
desc "Delete aggregate coverage data."
task(:clean) { rm_f "coverage.data" }
end
desc 'Aggregate code coverage for unit, functional and integration tests'
  task :coverage => "test:coverage:clean"
    %w[unit functional integration].each do |target|
    namespace :coverage do
      Rcov::RcovTask.new(target) do |t|
      t.libs << "test"
      t.test_files = FileList["test/#{target}/*_test.rb"]
      t.output_dir = "test/coverage/#{target}"
      t.verbose = true
      t.rcov_opts << '--rails --aggregate coverage.data'
    end
  end
  task :coverage => "test:coverage:#{target}"
  end
end

You can then run rcov on your rails app by running:

rake test:coverage

After this completes, it will output index.html files in RAILS_ROOT/tests/coverage/[units, functional, integration]. There is no overall index file, as, if you read the rake task, it is running rcov separately for each of [units, functional, integration].

Rcov has a few things to work out like showing untested code in modules sometimes, but otherwise it gives you a good idea of sections and branches of your code that are not tested. It’s very easy to set up so why not give it a try. But remember, metrics can only help point out problem spots in your code, they are not a replacement for good coding techniques.

• oracle-instantclient-basic-10.2.0.3-1.i386.rpm
• oracle-instantclient-devel-10.2.0.3-1.i386.rpm

(Note: this should work fine with the newer versions as well)

As root

cd PATH_TO_RPMS
rpm -ivh oracle-instantclient-basic-10.2.0.3-1.i386.rpm oracle-instantclient-devel-10.2.0.3-1.i386.rpm
echo /usr/lib/oracle/10.2.0.3/client/lib/ > /etc/ld.so.conf.d/oracle-instant-client-i386.conf

This last step, the echo, is a bit of magic. The conf files in /etc/ld.so.conf.d are run before each command is invoked to set your library path. The enviroment variable $LD_LIBRARY_PATH overrides these. You won’t see the contents of these files in your $LD_LIBRARY_PATH, but the application will. If your distribution doesn’t have an /etc/ld.so.conf.d directory, you can just add /usr/lib/oracle/10.2.0.3/client/lib to your LD_LIBRARY_PATH inthe /etc/profile, ~/.bash_profile, or any of the other more common places.

Now you need to find the latest ruby-oci8, check http://ar.rubyonrails.com/ and put it in /usr/local/src/

wget http://rubyforge.org/frs/download.php/36134/ruby-oci8-1.0.1.tar.gz
tar -xzvf ruby-oci8-1.0.1.tar.gz
cd ruby-oci8-1.0.1
ruby setup.rb config
make
make install

The previous versions of oci8 and ora instant clients required that you make several symlinks, and was a pain to set up. With the current oci8 and the instant clients on your LD_LIBRARY_PATH, the compile and install should work just fine.

With rails 2.1 out, the activerecord-oracle-adapter is no longer hosted on gems.rubyonrails.org. You can see this with a “gem list -r –source http://gems.rubyonrails.org”. So you have to do the ugly method of directly grabbing the adapter yourself. It is very easy though:

wget -P /usr/lib/ruby/gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_adapters/  http://svn.rubyonrails.org/rails/adapters/oracle/lib/active_record/connection_adapters/oracle_adapter.rb

That’s it. Just remember to make sure that you grab the right versions of everything.

<div class="right" id="main_right">
<div id="sidebar">
<%= yield :sidebar%>
</div>
</div>

Then in the view for the page, you need to define the content for each section, for sidebar I have:

<% content_for :sidebar do %>
<h2>Please Login</h2>
<div class="content">
... full view code omitted ...
<% end %>

So my views are of the form of:

<% content_for :sidebar do %>
... sidebar content goes here ...
<% end %>
<% content_for :main do %>
... main content goes here ...
<% end %>

You can do this for an arbitrary number of sections.
One thing to note is that if you are converting and forget to put a content_for block around the code, your view will render empty.