It's somewhat a matter of preference, but of the three I would pick rspec or Test::Unit.  RSpec has been criticized for being over-engineered lately, but I really like:
- the matcher syntax (
value.should == 1 vs. assert_equal(value, 1)) 
- test names not confined to method names (
it "does something awesome" { ... } vs def test_it_does_something_awesome; ...; end) 
You can achieve both of these with TestUnit with some supporting libraries with relative ease... but I just prefer to use RSpec.
When you write code and test, usually (always?) it's better to start from the outside in: IE, write an integration test (a logged in user clicks a button to add $5.00 item to cart, then checks out, and pays. His credit card should be charged $5.00).  So rather than testing specific class behaviors (as you do with unit tests), you'll want to be creating objects in the database and making get / post / etc. calls that interact with the site in a similar way that the users web browser would, making your test penetrate the entire stack.
Lately I have liked using Steak inside of RSpec for my integration tests (using Capybara to facilitate the web interaction)
Once you build up your outer perimeter, then I would recommend you start focusing on the unit tests.
Unit tests can be fantastic for documenting a class's behavior.  I group them around methods  and describe what can be passed to the method, and what I expect to be returned.
describe Object do
  describe "#method" do
    it "returns 4 when passed 2" do
      ...
    end
   end
end