[rspec-users] RSpec makes me want to write better code

Ashley Moran ashley.moran at patchspace.co.uk
Sat Sep 27 20:04:29 EDT 2008

On Sep 27, 2008, at 9:17 am, Matt Wynne wrote:

> I wouldn't call this the 'rails way' particularly - I think it's  
> more of a general OO design philosophy that says the database is  
> just an implementation detail. I have gradually moved, over the  
> years, from feeling like the database needed to be the foundation of  
> my whole domain (and therefore have tight integrity rules etc) to  
> wishing it would just go away and stop bothering me. I like the way  
> ORMs let me work in code most of my day rather than having to drop  
> into the database to find out what the rules are.


I agree with you - to am extent.  The thing is, with a full suite of  
stories (that work through the public interface) your *entire app* is  
an implementation detail.

<aside type="anecdote">
The other day I was going over some example code with a client.  I  
prepared it for a user stories + Cucumber + Celerity talk/workshop,  
although I don't think I'll need it now.  It was a crude one- 
controller CRUD (well CR, anyway) app written in Ramaze, for  
simplicity.  The plan was to build a fuller Merb app to build on  
later.  The only reason I was going to switch to Merb was because this  
client is considering it, and was more than happy when I suggested  
doing some research on it on my time.  But I knew this could raise the  
issue "the first one was a prototype, and Ramaze is a prototyping  
framework".  Even more so because the data store was this:

   class EventsController < Ramaze::Controller
     EVENTS = [ ]

     # ...

     def create
       EVENTS << request[:event_name]

Which led us on to a discussion about what exactly *is* a prototype,  
and what is a primitive production app.  (I've had to pull the slides  
for this, I think it'd be a talk on itself.)  So I said, "Hmmmmmmm,  
how long *would* it take to port to Merb?"  Not wanting to let our  
coffee go cold, I set to it... and 10 mins later, five of which was  
faffing around working out the differences between Ramaze and Merb  
controllers, it was running.  Indeed, Cucumber told us so before I  
loaded the page in a browser, as it implemented this:

Feature: Event creation
   So that Potential Delegates know an Event is happening
   As an Organiser
   I want to create Events

   # ...

   Scenario: Multiple event creation
     GivenScenario Successful Event creation
     Given I am on the Event creation page
     When I submit valid Event details for event 'My Second Event'
     Then the Events index page should show 'List of events'
     And it should show 'My Second Event'
     And it should show 'My First Event'
     And it should not show 'No events, please come back later'

Eventually my client decided that, on the basis that I evolved the  
code rather than throwing it away and re-writing it, that it was  
actually a primitive production app.  And it stores the data in an  
array in the controller.  More surprisingly, he decided that - on the  
basis it has no runnable specs - his own 2-year-old app serving  
several clients is a prototype!

So anyway, my point is, if you disparage the database on the premise  
it's an implementation detail, you should apply equally little concern  
to every other part of the app.

The reality I've found is that you find uses and insight in data long  
after you initially decided how to model it - possibly long after you  
stopped maintaining your app.  And I've been in the situation of  
having to unravel garbage and data corruption because someone didn't  
enforce DB integrity.

I think every component of an app should receive the same attention to  
quality.  It's impossible to know where an edge case will sneak past  
and bite you, so you have to cover as much as possible.

(Sorry if that was even rantier than usual - but I have a thing for  
data quality!!!)



More information about the rspec-users mailing list