[rspec-users] Assumption tests

Daniel Tenner daniel.ruby at tenner.org
Sat Oct 20 14:05:52 EDT 2007

On 20 Oct 2007, at 17:34 20 Oct 2007, David Chelimsky wrote:

> Agreed. This is exactly why we talk about stories and specs instead of
> integration and units. I realize that I've slung the term integration
> tests around when talking about about stories so I apologize if I've
> added to the confusion.
> The distinction we make between stories and specs is that stories
> describe how a system behaves in terms of a user's experience, whereas
> specs describe how an object behaves in terms of another object's
> experience.

If a spec describes how an object behaves in terms of another  
object's experience, doesn't that mean that a spec describes an  
object's interactions with other objects?

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

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.

Fundamentally, I think the focus shift is from "what just happened"  
to "what happens next". i.e.:

TDD: Foo. Is Bar set to the right value? What about Baz?

BDD: This should happen; then this should happen; then this. Tell me  
if that doesn’t happen when I say “foo”. Foo.

This is the way I'm seeing it at the moment and the reason why I'm  
resisting writing things like @something.should be_somestate in my  
specs, which I think is a test of what just happened rather than a  
specification of what should happen next.

Also, interestingly, I'm finding I don't have that resistance when  
writing Stories, which I regard as just "better written integration  
tests" (which are critical to making sure that all those behaviour  
specs actually amount to a working system).

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.


More information about the rspec-users mailing list