If you’re just getting started with testing (and general test-first or test-driven development) in your Ruby and Ruby on Rails applications, you have a couple of choices.

You can go with Ruby’s Unit::Test, built right in to Ruby, and built-in to Rails with unit, functional, and integration test suites setup for you.

Or, you could setup Rspec with Mocha, and implement a form of testing called Behavior Driven Development or BDD.

Both approaches serve the same goal: better, tested code, easier code to maintain, and in general, just better practices.

My advice is to start with unit tests, and then move to Rspec later.

Once you get the hang of the built-in unit testing framework, you’ll start to write tests named like this:

    def test_login  # end  def test_create  # end 

which is fine, and gets the job done (I do it like this!).
Eventually, after getting the hang of it, you’ll start to write
shorter and shorter tests named like this:

    def test_should_allow_login  # ... end  def test_should_not_let_user_view_admin_page  # ... end 

etc. etc.

And next thing you know, you’re doing a form of behavior driven development, but without Rspec (I do this too – and yes I know, it’s not completely rspec – it lacks the mocking/stubbing
non-boundary-crossing unit-test tools). But, there’s a lot more documentation and examples out there as of right now using good ole unit testing.

I forget where I read somewhere that David Heinemeier Hansson (DHH) doesn’t use Rspec (yet), but writes his test with the Rspec style should and should_not methods, and tries to adhere to good, single units of functionality and behavior in tests.

If you install plugins in your Rails application, they will have their own tests, but they don’t actually run in conjunction with your code. So, while you should run a plugin’s tests once you pull down the code – you don’t really need to run them again. You’ll be writing your own tests, that may execute parts of the plugins code, and that can be your own flavor/style.

It will feel at first like you are troubleshooting tests, along with code – which is irritating, I know, but stick with it. It takes longer in the beginning, but is well worth it, once you get going.

I recommend treating your tests like debugging statements, and using puts statements everywhere while you figure it out, so that when you run your tests (hopefully using Apple-R while inside Textmate, or using the Run-command in most other editors), you can see:

    puts "widget should have errors: #{@widget.errors.inspect}" assert !@widget.errors.empty? 

Of course, be sure to remove or comment out those puts statements before you check in your tests. You can always uncomment them for debugging later.

A former Big Nerd Ranch alumni says:

A great tool to help migrate between Test::Unit and RSpec / BDD is the plugin Shoulda.

It looks a lot like RSpec / Test::Spec but it is all just decoration on top of Test::Unit. You get a lot of really nice tools like nested contexts, which help hierarchically structure your tests, and some excellent ActiveRecord association and validation tests.