Ashley, your response perfectly words what I was thinking reading this
thread..
I haven't done much with merb yet, but just reading the code, I would
guess that if you include Merb::Test::ControllerHelper in your spec,
then you'd be helped with the method
merb-core:/lib/merb-core/test/helpers#dispatch_to ?
from the doc:
# Dispatches an action to the given class. This bypasses the
router and is
# suitable for unit testing of controllers.
# ==== Example
# dispatch_to(MyController, :create, :name => 'Homer' ) do
|controller|
# controller.stub!(:current_user).and_return(@user)
# end
Lawrence
> In response to Per, Matt and Yehuda: I share the same concerns as Jarko.
>
> My BDD strategy currently is this:
>
> * Cucumber feature descriptions to drive the app the app with
> Celerity. This works ONLY through the public HTTP API, meaning I will
> extend that API to allow it to force a given state. (There's a simple
> example of how I do all this on my blog[1].)
>
> * RSpec behaviour examples for the controller, with all models stubbed.
>
> * RSpec behaviour examples for individual models, avoiding DB access
> where possible.
>
> * RSpec behaviour examples for multi-model persistence where
> necessary. (Less important, as the feature descriptions should cover
> this behaviour unless it's unusually complex.)
>
> I saw the generated resource specs, and have to admit I immediately
> deleted them and regenerated a standard controller. (However, the
> resource controller itself is a really useful example.)
>
> My opinion of controller specs is two-sided. On one hand, that they
> are too low level to allow a simple description of the app's
> behaviour, because multi-action user stories involve setting state
> between examples (aka making fragile assumptions). They are also
> limited to describing behaviour in terms of resource requests, which
> may not be enough if your GUI is complex (eg has a lot of JavaScript,
> or isn't even in web browser at all.) However, this belief comes from
> time spent with Rails, not Merb. On the other hand, controller specs
> are too high level to cover all the possible behaviours of an app.
>
> In my mind, the controller is just a facade than translates HTTP
> requests to business logic statements, and translates business data
> into HTTP responses. And that's all I want to spec really, that it
> sends the right things backwards and forwards.
>
> Another mental model is application surface area. The stereotypical
> RESTful CRUD Rails app is high surface area: lots of HTTP actions, low
> code complexity per action. In the degenerate case of this (an app
> that runs entirely off scaffolded resources), you don't need any
> controller or model specs- feature files would do. The opposite end
> of the spectrum is a low surface area, high complexity app, such as
> finance calculations, fleet management or accounting. These have
> almost innumerable edge cases and need a thorough model-level spec
> suite to fully describe their intended behaviour.
>
> But in both cases, the controller is doing the same job, and its
> complexity should be fairly (I hesitate to say entirely) independent
> of the client-side functionality (again, eg JavaScript) and the model
> functionality.
>
> Phew, I think that was more of a blog post than a mailing list reply.
> Rant over!
>
> I'm interested to hear more of the merb community's opinions of BDD in
> a merb app. The fact that the resource controller generator creates
> valuable spec files is encouraging, even if I disagree with the
> responsibility those specs should be afforded.
>
> Cheers
> Ashley
>
>
> [1] aviewfromafar.net/2008/10/2/geekup-sheffield-vi-from-specification-
> to-success
> (look for the code link, the rest is irrelevent)
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"merb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/merb?hl=en
-~----------~----~----~----~------~----~------~--~---
