From http://www.reevoo.com/blogs/bengriffiths/2005/06/24/a-test-by-any-other-name/:

We find that the pattern ‘test_should_***_on_***’ a useful way of naming tests – it’s an idea stolen from JBehave . If this test were to fail, I’m reminded that I should (!) ask myself the question ‘should the class I’m testing do this?’ before I go on a bug-hunt. The other advantage is that I can use my test classes to generate some simple documentation for my classes. Here’s a rake target that can do just that:

desc "Generate agiledox-like documentation for tests"
task :agiledox do
  tests = FileList['test/**/*_test.rb']
  tests.each do |file|
    m = %r".*/([^/].*)_test.rb".match(file)
    puts m[1]+" should:\n"
    test_definitions = File::readlines(file).select {|line| line =~ /.*def test.*/}
    test_definitions.each do |definition|
      m = %r"test_(should_)?(.*)".match(definition)
      puts " - "+m[2].gsub(/_/," ")
    end
  puts "\n"
 end
end

An example from our codebase, typing rake agiledox generates:

security_controller should:
- redirect to page stored in session on successful login
- store user object in session on successful login
- redirect to page stored in session after signup
- store user object in session after signup
- reject signup when passwords do not match
- reject signup when login too short
- report both errors if passwords dont match and username too short
- not store user in session if password not correct on signup
- remain on login page if password not correct on signup
- remove user from session on log out