David C. wrote:
Actually, this is not true at all. The rspec_on_rails plugin does, in
fact, wrap Test::Unit::Test case so you have access to all of the
facilities of test/unit in spec/rails.
Actually, that is not entirely true either 
You get all the test/unit assertions, and you get most of the fixture
support.
You get it all with:
config.fixture_path = RAILS_ROOT + ‘/test/fixtures’
Curiously, we discovered that using “it_should_behave_like
‘MyAbstractSpec’”
conflicted with fixtures. Adding fixtures :my_records after that line,
and
another in MyAbstractSpec, produced this:
behaviour_eval.rb:137:in method_missing': undefined method fixtures’
for
#Spec::DSL::EvalModule:0x2a9869e548 (NoMethodError)
from ./spec/models/subscription_spec.rb:5
We worked around this by simply pouring in all the fixtures:
config.global_fixtures = :party, :supplies
You also can plug in Mocha, an automated mock system, using this line in
spec/spec_helper.rb:
config.mock_with :mocha
Both Mocha and RSpec are “Domain Specific Languages” with a declarative
syntax. You declare what you need as a string of operations, and the
system
evaluates them simultaneously (not strictly procedurally, from left to
right), to generate a conclusion.
So here’s a behavior for a webservice
it “will delete the remote record” do
RIO::Rio.expects(:rio).with{ |uri| uri =~ /DELETE/ }
result = @local_record.delete_remote_record
result.should eql(true)
end
Mocha expects Rio to call its class-method rio() with an URL containing
(at
least) “DELETE” when our local record calls its delete_remote_record()
method, and that should return true.
Most items should not be mocked. Your tests and specs should be very
lean
because most of your production objects should strongly decouple. Rio is
a
special case because it calls another website, and we don’t need to hit
that
live site each time we run the tests. (We’ve had requests to stop;)
–
Phlip
Test Driven Ajax (on Rails) [Book]
“Test Driven Ajax (on Rails)”
assert_xpath, assert_javascript, & assert_ajax