[rspec-users] Assumption tests

Ashley Moran work at ashleymoran.me.uk
Sat Oct 20 15:28:36 EDT 2007

On Oct 20, 2007, at 7:05 pm, Daniel Tenner wrote:

> I know I keep coming back to this. I promise I'm not doing it to be a
> pain, but because I'm curious about whether there is something in
> pushing this thing to extreme and saying "it's not a spec unless it
> describes what the object _does_" (as opposed to an outcome once the
> object does something).

Well just the other day, I wrote two equally small classes that I  
specced in different ways.  One used open-uri, and the spec stubs out  
the call and return value.  The other extracted the <title> element  
from HTML using Hpricot, but the spec never mentioned Hpricot.  Aside  
from the obvious need to avoid real network connections, I just had a  
gut feeling that one was more suitable to interaction-based speccing  
than the other.  It seemed that the methods called on the Hpricot  
library were irrelevant, as long as it sent the correct string back,  
yet I've written other code, both simpler and more complex, that I  
felt the need to mock out.

> Here's where I'm coming from. Take http://behaviour-driven.org/
> TDDAdoptionProfile as the compass of where we're going. Then, if
> we're only using BDD as "TDD done right", we're actually still stuck
> at step 5, testing what  the object looks like after we prod it in a
> certain way. Instead, we should be defining behaviour, ie what the
> object actually does, both internally and externally, in response to
> a prod.

I didn't get the impression from that article that there was anything  
magical about steps 6 and 7.  If anything, I interpreted it as "if  
you're at step 7, you can say your TDD is 'done right' and deserves  
to be called BDD".  I'm assuming people talked about the behaviour  
discovered doing TDD, before the term BDD was drawn up.  I don't know  
- I wasn't around then.

> I guess the question someone could ask here is "if your specs are not
> proving that your system works, what do they prove?" - my answer to
> that is that they prove that my code is still doing what I specified
> it should do - e.g. if i specified that when I call a certain method
> the current user should receive a :delete call, the spec ensures that
> this continues to happen no matter what other things i specify that
> that method should do.

To me, they prove that a subsystem works.  They mean you can add a  
single model validation without having to retest the entire app - as  
long as you know your controller checks that all models are valid,  
you don't really care what those validations are.  Specs let you  
check these little bits code in every conceivable way, when the  
permutations they make as part of the larger app would be almost  

That's my current opinion at least, although it gets revised on an  
almost weekly basis.


blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home

More information about the rspec-users mailing list