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. Daniel _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
