From http://www.railtie.net/articles/2006/09/17/tagging-your-test-cases:
Here's a quick way to follow your tests a little more closely in your test.log. In your test setup, add the following line:

def setup
  RAILS_DEFAULT_LOGGER.debug "\n\e[0;31mRUNNING TEST CASE: #{name}\e[m\n"
end

From http://newbieonrails.topfunky.com/articles/2006/07/28/foscon-and-living-dangerously-with-rake:
Updated from : http://mentalized.net/journal/2006/07/28/run_specific_tests_via_rake/

If you define a rule with an empty string, you can catch any task that hasn’t been defined elsewhere. This makes it easy to dynamically create rake tasks. Essentially, this is method_missing for rake!

rule "" do |t|
  t.name 
  # ... do something with the name of the task  
end

I experimented by writing a rule that will take a task with the format of controllername_testname and automatically run a single test from the relevant functional or unit test.

##
# Run a single test in Rails.
#
#   rake blogs_list
#   => Runs test_list for BlogsController (functional test)
#
#   rake blog_create
#   => Runs test_create for BlogTest (unit test)

rule "" do |t|
  if /(.*)_([^.]+)$/.match(t.name)
    file_name = $1
    test_name = $2
    if File.exist?("test/unit/#{file_name}_test.rb")
      file_name = "unit/#{file_name}_test.rb" 
    elsif File.exist?("test/functional/#{file_name}_controller_test.rb")
      file_name = "functional/#{file_name}_controller_test.rb" 
    else
      raise "No file found for #{file_name}" 
    end
    sh "ruby -Ilib:test test/#{file_name} -n /^test_#{test_name}/" 
  end
end

Update from : http://mentalized.net/journal/2006/07/28/run_specific_tests_via_rake/
This modified version uses a different syntax (rake test:foo:bar instead rake foo_bar) and regex matching for test names.

Usage

$ rake test:blog
=> Runs the full BlogTest unit test

$ rake test:blog:create
=> Runs the tests matching /create/ in the BlogTest unit test

$ rake test:blog_controller
=> Runs all tests in the BlogControllerTest functional test

$ rake test:blog_controller:create
=> Runs the tests matching /create/ in the BlogControllerTest functional test	

Code

# Run specific tests or test files
# 
# rake test:blog
# => Runs the full BlogTest unit test
# 
# rake test:blog:create
# => Runs the tests matching /create/ in the BlogTest unit test
# 
# rake test:blog_controller
# => Runs all tests in the BlogControllerTest functional test
# 
# rake test:blog_controller
# => Runs the tests matching /create/ in the BlogControllerTest functional test	
rule "" do |t|
  # test:file:method
  if /test:(.*)(:([^.]+))?$/.match(t.name)
    arguments = t.name.split(":")[1..-1]
    file_name = arguments.first
    test_name = arguments[1..-1] 
    
    if File.exist?("test/unit/#{file_name}_test.rb")
      run_file_name = "unit/#{file_name}_test.rb" 
    elsif File.exist?("test/functional/#{file_name}_test.rb")
      run_file_name = "functional/#{file_name}_test.rb" 
    end
    
    sh "ruby -Ilib:test test/#{run_file_name} -n /#{test_name}/" 
  end
end

Do whatever you want with the above code, it’s yours now.

This snippet comes from Jamie Cansdale at TestDriven.net (http://weblogs.asp.net/nunitaddin/archive/2006/06/07/ClassLibrary-Projects-and-App.config.aspx)

In Visual Studio .NET 2003 if you want you unit tests to use an app config file you need to ensure a config file exists with the same path as your test assembly but ending with '.config'. Life has improved a bit with Visual Studio 2005 as it will automatically copy any 'App.config' file to the correct place even for ClassLibrary projects. You can achieve the same affect in VS2003 by using the following post-build event:

copy "$(ProjectDir)App.config" "$(TargetPath).config"

making functional test failures readable

By zenspider on Rails

Tired of your rails functional test failures being completely unreadable? I'm not terribly fond of rails' assert_tag but it is better than nothing. However, I never like to read something like the following:

expected tag, but no tag found matching {:attributes=>{:action=>"/admin/themes/update/1"}, :tag=>"form"} in:
"<!DOCTYPE [...3k worth of crap cut...]</html>".

Ugh! It just does nothing to help you and since it isn't expressed as a diff, unit_diff is no help in this arena. I have however figured out how to make it much more manageable with the following snippets:

class ApplicationController < ActionController::Base
 def initialize(testing=false)
 super()
 self.class.layout(nil) if testing
 end
 [...]
end

and then in your functional tests:

def setup
 @controller = MyController.new(true)
 [...]
end

Now your failures contain just the content from the page:

expected tag, but no tag found matching {:attributes=>{:action=>"/admin/themes/update/1"}, :tag=>"form"} in:
"\n<ul>\n <li>Name: Blue</li>\n <li>Folder: blue</li>\n <li>Description: A Plain blue theme</li>\n <li>Masthead: Blue</li>\n <li>Editor: n/a</li>\n</ul>\n\n<a href=\"/admin/themes/show/1\">Cancel Editing</a>\n".

From: http://www.karmiccoding.com/articles/2006/03/11/under-the-hood-with-ruby-partial-mock-objects-for-unit-testing

"What happens though, if you want to override a class in an instance of an object, and not all of its kind? Typically you would define a mock object, and create an instance of it. But, in Ruby there is an easier and faster way that doesn’t involve writing a different mock class for each different scenario – and it is made possible by the singleton class. This clever bit of ruby hackery lets you override the behaviour of a single instance of a class, creating what I’ve decided to call a partial mock object. To demonstrate, I’ve written a small method called override_method which will override the behaviour of the specified method in the passed object, like so:

# Overrides the method +method_name+ in +obj+ with the passed block
def override_method(obj, method_name, &block)
  # Get the singleton class/eigenclass for 'obj'
  klass = class <<obj; self; end 

  # Undefine the old method (using 'send' since 'undef_method' is protected)
  klass.send(:undef_method, method_name)

  # Create the new method
  klass.send(:define_method, method_name, block)
end

# Just an example class
class Foo 
  def do_stuff
    "I'm okay!" 
  end
end

# Test code
list = []
5.times { list.push(Foo.new) }

# We override the method here!
override_method(list.first, :do_stuff) { "I'm NOT okay!" }

list.each_with_index { |f, i| puts "(#{i}) #{f.do_stuff}" }

Outputs:
(0) I'm NOT okay!
(1) I'm okay!
(2) I'm okay!
(3) I'm okay!
(4) I'm okay!

As you can see, only the first object in the array’s behaviour has been changed – the rest have remained untouched. Because of this, you can embed these partial dynamic mock objects deeply into your code without the need to specially instantiate a mock object deep in your code, or writing a ‘clever mock’ to only trigger the determined behaviour in certain objects.

Where this code comes in really handy is when you need an object to raise a difficult to simulate exception (like a disk full error) on a certain method to test your error handling – simply call override_method and pass in a call to raise and voila! Dynamic partial mock objects on the fly!"