[rspec-users] Assumption tests
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
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
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