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