On 20 Oct 2008, at 06:51, Jarkko Laine wrote:
> Could you elaborate with the decision a bit, since I smell there's a
> bit of a conflict with the Rspec/BDD ideas here? It seems to me that
> the new way of testing in Merb is exactly the same as using story
> runner/Cucumber, except that it doesn't really test the whole stack
> like using stories with Webrat does.
>
> Also, are you still encouraging unit testing for models or do you
> think the full-request testing should take care of testing them as
> well?
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)
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
