Awesome! That's a whole lot more of a response than I had
anticipated. Thanks!
On Sep 12, 2007, at 6:15 PM, David Chelimsky wrote:
On 9/12/07, Evan David Light <[EMAIL PROTECTED]> wrote:
I like to start w/ integration tests before anything exists at all.
You can do that w/ Rails' Integration Tests or Story Runner (if you're
using RSpec's trunk).
Story Runner is a new one for me. I'll have to look it up. Thanks!
(Halfway through writing this, I realized, courtesy of Google, that
it's a recently integrated piece of functionality into RSpec-on-
Rails. I found this example of yours captured here. )
I see why this could be a good way to start coding. This is exactly
what I naturally wanted to do with RSpec but couldn't because RSpec
seems oriented toward a lower-level set of issues. I'll have to
start playing with the trunk now. This looks nifty.
If you don't want broken software, then spec the views - but ONLY
the stuff that actually has business value.
Seems like sound common sense. I caught myself earlier today writing
a spec for a non-functional portion of my view, chided myself for it,
ripped out the spec, and then continued.
Once the view is sufficiently spec'd and the specs are passing, I know
what the controller needs to supply, so I start spec'ing the
controller. And on down to models.
Good to realize that I'm not thinking that far off the mainstream here.
That's not to say that the philosophy isn't important. I, personally,
love talking about philosophy. It helps me to understand why I
gravitate towards the things I do.
Ultimately, this is what I was looking for: not so much "what to do"
but the "tao" of it. Starting with the user in mind, from a view
level, made some sense but too minutiae driven. I like to dabble
with new approaches but always asking "why?" along the way. While a
lot of what I have been doing with RSpec could be accomplished with
Test::Unit, I'm finding that I prefer the RSpec approach somewhat more.
Same w/ approaches to testing and developing software. Agile isn't all
that agile if we're all finding "best practices" and applying them
like a bunch of blind followers of some religion.
Or if we spend so much time on "best practices" that we're not
actually accomplishing anything? Welcome to the government. ;-)
"We have come to
value individuals and interactions over processes and tools," yet
we're always becoming slave to the next tool rather than becoming its
master and sticking it in our tool belt.
<wisecrack> You mean that instead of being Java Juju Zombies that
we're becoming Ruby Robots? </wisecrack>
Summing up - the series of steps I described above is what I *usually*
do because I know it works for me and the way I work. But I don't do
that 100% of the time, and I certainly don't feel bad when I break
that pattern. It's just a great tool to have lying around.
And, of course, what works for one may not work for all. However,
with regard to Rails apps, I'm still finding my way. That said, I
know that I would prefer a TDD/BDD approach to writing it, hand
testing it, seeing it mostly work, fix something (and perhaps
breaking something else!), rinsing and repeating.
Thanks for the brain dump!
Evan
IMs (all): sleight42
http://evan.tiggerpalace.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
