[rspec-users] Philosophical questions

David Chelimsky dchelimsky at gmail.com
Wed Sep 12 19:35:08 EDT 2007

On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote:
> Awesome!  That's a whole lot more of a response than I had anticipated.

Me too.

> Thanks!
> On Sep 12, 2007, at 6:15 PM, David Chelimsky wrote:
> On 9/12/07, Evan David Light <evan at tiggerpalace.com> 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. )

Not specific to Rails at all. Just happens to support Rails.

> 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.

Careful here. Business value is not always measured in terms of things
"functional". Sometimes it's the company logo showing up in the right
place on the page after spending thousands of marketing dollars
figuring out where that spot is.

> 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.

Eeeek. You're not thinking far off from ME. That in no way makes it main stream.

> 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!

Thanks for cleaning it up!!!


More information about the rspec-users mailing list