I would do the same thing, as Test::Unit's syntax is more confusing to a newbie than RSpec. For instance: assert_equal 2, @thing.method vs @thing.method.should == 2.
RSpec is also used by the majority of Rails developers (based on a random stat I pulled out of the air and due to my experience on many, many Rails projects) and it should be treated as the default, even though it is not.
> For instance: assert_equal 2, @thing.method vs @thing.method.should == 2.
...what makes you think this is less confusing? Test::Unit is blindingly simple, your assertions are plain old functions that take plain old arguments. I can build new assertions through simple function definition.
Rspec, on the other hand, adds methods to everything to let you structure your code so it reads like English. The goal here is not to be less confusing, but to be easier to read. RSpec is a lot harder to learn, and writing custom matchers is a lot more work than gluing together assertions.
Seriously, watch somebody new trying to figure out RSpec ... it's a bit of an ugly sight. Their first experience with automatic predicate matchers typically is a true wtf moment.
RSpec is also used by the majority of Rails developers (based on a random stat I pulled out of the air and due to my experience on many, many Rails projects) and it should be treated as the default, even though it is not.