On Jun 7, 2008, at 3:10 PM, Kyle Hargraves wrote:
I'm looking to drive the development of a rails app that does nothing
but serve a JSON API. All of the models are well tested elsewhere, so
I needn't worry about that. My only immediate goal is to be able to
fire off requests to a path and check the returned JSON.
I've tried a number of methods for this today, without being
particularly enthused about any of them.
I started with user stories, but the conversion to english was
difficult for something largely developer-facing. "When I get
/widgets/:id" where :id is actually determined behind the scenes did
not read well, and a lot of my expectations were tough to express in
sentence form. I've had a lot of success with stories in the
application that is related to this API, but they don't seem to fit
well here.
Can you post an example or two? I'd like to see what's not working for
you. No promises I can offer up anything better, but just curious.
I tried out using standard rails test/unit integration tests, but that
would be a suite largely divorced from all of my other specs, and I
miss the :should syntax. Requiring spec/expectations and spec/matchers
alleviated some of that, but
test_names_end_up_being_unpleasantly_long_and_cumbersome. I haven't
yet looked at the test/unit interop support, but maybe that would be
helpful here?
I tried to make an IntegrationExampleGroup akin to the other rails
example groups:
module Spec::Rails::Example
class IntegrationExampleGroup < ActionController::IntegrationTest
Spec::Example::ExampleGroupFactory.register(:integration, self)
end
end
describe 'GET /widgets', :type => :integration do
it "should ..." do
get '/widgets'
[...]
end
end
This roughly seems to work for the integration tests (I'd still need
to add in transactions, maybe a few other things), but for reasons I
haven't yet figured out means all my other specs try to run within an
integration session.
That definitely shouldn't happen. What you have here is very close to
what
Finally, I could just test the serialization methods on the model (or
build a WidgetSerializer), and then use mocks in controller specs. But
I'm really looking for full-stack specs here, so I'd like to avoid
that.
Any suggestions? The path of least resistance is probably using the
test/unit tests, followed closely by just sucking it up and having
awkward user stories. My preferred solution would be the
IntegrationExampleGroup, and I may yet get that to work, but I thought
I'd ask here while I sit on it for a bit.
The IntegrationExampleGroup should work. Let's try to figure out why
you're getting bleed into the other groups.
Cheers,
David
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users